valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-07 08:58:59 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #25979 from basepi/merge-forward-2015.8

Browse Source 
[2015.8] Merge forward from 2015.5 to 2015.8
This commit is contained in:
Colton Myers 2015-08-03 17:15:52 -06:00
commit 2e792130f4
22 changed files with 549 additions and 288 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
conf/master
View File

@ -356,12 +356,12 @@
# 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
#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
#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
@ -381,7 +381,7 @@
#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
# setting to 'True'. Or pass a list of state module names to automatically
# aggregate just those types.
#
# state_aggregate:
@ -389,6 +389,11 @@
#
#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

48
doc/ref/configuration/master.rst
View File

@ -908,6 +908,41 @@ If set to 'changes', the output will be full unless the state didn't change.
state_output: full
.. conf_master:: state_aggregate
``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.
.. code-block:: yaml
state_aggregate:
- pkg
.. code-block:: yaml
state_aggregate: True
.. conf_master:: state_events
``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>``.
.. code-block:: yaml
state_events: True
.. conf_master:: yaml_utf8
``yaml_utf8``
@ -2308,10 +2343,21 @@ 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:
.. code-block:: yaml
syndic_master:
- masterofmasters1
- masterofmasters2
Each higher level master must be set up in a multimaster configuration.
.. conf_master:: syndic_master_port
``syndic_master_port``
-----------------------
----------------------
Default: ``4506``

2
doc/ref/configuration/minion.rst
View File

@ -553,7 +553,7 @@ 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, as all modules are loaded into ram
disabling modules will lover the minion's ram footprint.
disabling modules will lower the minion's ram footprint.
.. code-block:: yaml

5
doc/topics/eauth/index.rst
View File

@ -78,6 +78,11 @@ append a ``%`` to the ID:
- '*':
- 'pkg.*'
.. warning::
All users that have external authentication privileges are allowed to run
:mod:`saltutil.findjob <salt.modules.saltutil.find_job>`. Be aware
that this could inadvertently expose some data such as minion IDs.
.. _salt-token-generation:
Tokens

9
doc/topics/event/master_events.rst
View File

@ -86,6 +86,15 @@ Job events
:var fun: The function the minion ran. E.g., ``test.ping``.
:var return: The data returned from the execution module.
.. salt:event:: salt/job/<JID>/prog/<MID>/<RUN NUM>
Fired each time a each function in a state run completes execution. Must be
enabled using the :conf_master:`state_events` option.
:var data: The data returned from the state module function.
:var id: The minion ID.
:var jid: The job ID.
.. _event-master_presence:
Presence events

9
doc/topics/highavailability/index.rst
View File

@ -63,3 +63,12 @@ of Masters" nodes can control multiple segments underneath them.
Syndics are covered in depth in :doc:`Salt Syndic </topics/topology/syndic>`.
Syndic with Multimaster
=======================
.. versionadded:: 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 :doc:`Salt Syndic </topics/topology/syndic>`.

239
doc/topics/topology/syndic.rst
View File

@ -4,102 +4,207 @@
Salt Syndic
===========
The Salt Syndic interface is a powerful tool which allows for the construction
of Salt command topologies. A basic Salt setup has a Salt Master commanding a
group of Salt Minions. The Syndic interface is a special passthrough
minion, it is run on a master and connects to another master, then the master
that the Syndic minion is listening to can control the minions attached to
the master running the 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.
The intent for supporting many layouts is not presented with the intent of
supposing the use of any single topology, but to allow a more flexible method
of controlling many systems.
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
======================
Since the Syndic only needs to be attached to a higher level master the
configuration is very simple. On a master that is running a syndic to connect
to a higher level master the :conf_master:`syndic_master` option needs to be
set in the master config file. The ``syndic_master`` option contains the
hostname or IP address of the master server that can control the master that
the syndic is running on.
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:
The master that the syndic connects to sees the syndic as an ordinary minion,
and treats it as such. the higher level master will need to accept the syndic's
minion key like any other minion. This master will also need to set the
:conf_master:`order_masters` value in the configuration to ``True``. The
``order_masters`` option in the config on the higher level master is very
important, to control a syndic extra information needs to be sent with the
publications, the ``order_masters`` option makes sure that the extra data is
sent out.
On the Syndic node:
To sum up, you have those configuration options available on the master side:
.. code-block:: yaml
- :conf_master:`syndic_master`: MasterOfMaster ip/address
- :conf_master:`syndic_master_port`: MasterOfMaster ret_port
- :conf_master:`syndic_log_file`: path to the logfile (absolute or not)
- :conf_master:`syndic_pidfile`: path to the pidfile (absolute or not)
# /etc/salt/master
syndic_master: 10.10.0.1 # may be either an IP address or a hostname
Each Syndic must provide its own ``file_roots`` directory. Files will not be
automatically transferred from the master-master.
.. code-block:: yaml
# /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:
.. code-block:: yaml
# /etc/salt/master
order_masters: True
The :conf_master:`syndic_master` option tells the Syndic node where to find the
Master node in the same way that the :conf_minion:`master` option tells a
Minion node where to find a Master node.
The :conf_minion:`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 :conf_master:`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
=======================================
.. versionadded:: 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 :doc:`Multimaster Tutorial </topics/tutorials/multimaster>`.
On the syndic, the :conf_master:`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 Syndic is a separate daemon that needs to be started on the master that is
controlled by a higher master. Starting the Syndic daemon is the same as
starting the other Salt daemons.
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:
.. code-block:: bash
# salt-syndic
or
# service salt-syndic start
.. note::
On the Master node:
If you have an exceptionally 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
:conf_master:`syndic_wait` value in the upper master config. The default
value is ``1``, and should work for the majority of deployments.
.. code-block:: bash
# 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:
.. code-block:: bash
# 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
========
The ``salt-syndic`` is little more than a command and event forwarder. When a
command is issued from a higher-level master, it will be received by the
configured syndics on lower-level masters, and propagated to to their minions,
and other syndics that are bound to them further down in the hierarchy. When
events and job return data are generated by minions, they aggregated back,
through the same syndic(s), to the master which issued the command.
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.
The master sitting at the top of the hierarchy (the Master of Masters) will *not*
be running the ``salt-syndic`` daemon. It will have the ``salt-master``
daemon running, and optionally, the ``salt-minion`` daemon. Each syndic
connected to an upper-level master will have both the ``salt-master`` and the
``salt-syndic`` daemon running, and optionally, the ``salt-minion`` daemon.
A Syndic node must run ``salt-syndic`` and ``salt-master`` daemons and
optionally a ``salt-minion`` daemon.
Nodes on the lowest points of the hierarchy (minions which do not propagate
data to another level) will only have the ``salt-minion`` daemon running. There
is no need for either ``salt-master`` or ``salt-syndic`` to be running on a
standard minion.
A Minion node must run a ``salt-minion`` daemon.
Syndic and the CLI
==================
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.
In order for the high-level master to return information from minions that are
below the syndic(s), the CLI requires a short wait time in order to allow the
syndic(s) to gather responses from their minions. This value is defined in the
``syndic_wait`` and has a default of five seconds.
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.
While it is possible to run a syndic without a minion installed on the same machine,
it is recommended, for a faster CLI response time, to do so. Without a minion
installed on the syndic, 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``.
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.
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
:conf_master:`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 :conf_master:`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.
- :conf_minion:`id`: Syndic id (shared by the ``salt-syndic`` daemon with a
potential ``salt-minion`` daemon on the same system)
- :conf_master:`syndic_master`: Master node IP address or hostname
- :conf_master:`syndic_master_port`: Master node ret_port
- :conf_master:`syndic_log_file`: path to the logfile (absolute or not)
- :conf_master:`syndic_pidfile`: path to the pidfile (absolute or not)
- :conf_master:`syndic_wait`: time in seconds to wait on returns from this syndic

14
doc/topics/windows/windows-package-manager.rst
View File

@ -170,6 +170,20 @@ Add ``cache_dir: True`` when the installer requires multiple source files. The
directory containing the installer file will be recursively cached on the minion.
Only applies to salt: installer URLs.
Alternatively the ``uninstaller`` can also simply repeat the URL of the msi file.
.. code-block:: yaml
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'
.. code-block:: yaml
sqlexpress:

8
salt/cloud/__init__.py
View File

@ -1681,11 +1681,11 @@ class Map(Cloud):
return {}
if not os.path.isfile(self.opts['map']):
raise SaltCloudNotFound(
'The specified map file does not exist: {0}\n'.format(
self.opts['map']
)
log.error(
'The specified map file does not exist: \'{0}\''.format(
self.opts['map'])
)
raise SaltCloudNotFound()
try:
renderer = self.opts.get('renderer', 'yaml_jinja')
rend = salt.loader.render(self.opts, {})

21
salt/cloud/cli.py
View File

@ -84,7 +84,11 @@ class SaltCloud(parsers.SaltCloudParser):
self.exit(salt.defaults.exitcodes.EX_OK)
log.info('salt-cloud starting')
mapper = salt.cloud.Map(self.config)
try:
mapper = salt.cloud.Map(self.config)
except SaltCloudException as exc:
msg = 'There was an error generating the mapper.'
self.handle_exception(msg, exc)
names = self.config.get('names', None)
if names is not None:
@ -163,12 +167,21 @@ class SaltCloud(parsers.SaltCloudParser):
elif self.options.destroy and (self.config.get('names', None) or
self.config.get('map', None)):
if self.config.get('map', None):
log.info('Applying map from {0!r}.'.format(self.config['map']))
map_file = self.config.get('map', None)
names = self.config.get('names', ())
if map_file is not None:
if names != ():
msg = 'Supplying a mapfile, \'{0}\', in addition to instance names {1} ' \
'with the \'--destroy\' or \'-d\' function is not supported. ' \
'Please choose to delete either the entire map file or individual ' \
'instances.'.format(map_file, names)
self.handle_exception(msg, SaltCloudSystemExit)
log.info('Applying map from \'{0}\'.'.format(map_file))
matching = mapper.delete_map(query='list_nodes')
else:
matching = mapper.get_running_by_names(
self.config.get('names', ()),
names,
profile=self.options.profile
)

2
salt/modules/artifactory.py
View File

@ -319,7 +319,7 @@ def __save_artifact(artifact_url, target_file, headers):
}
if os.path.isfile(target_file):
log.debug("File %s already exists, checking checksum...")
log.debug("File {0} already exists, checking checksum...".format(target_file))
checksum_url = artifact_url + ".sha1"
checksum_success, artifact_sum, checksum_comment = __download(checksum_url, headers)

4
salt/modules/drac.py
View File

@ -66,7 +66,7 @@ def system_info():
.. code-block:: bash
salt dell drac.getsysinfo
salt dell drac.system_info
'''
cmd = __salt__['cmd.run_all']('racadm getsysinfo')
@ -84,7 +84,7 @@ def network_info():
.. code-block:: bash
salt dell drac.getniccfg
salt dell drac.network_info
'''
cmd = __salt__['cmd.run_all']('racadm getniccfg')

2
salt/modules/event.py
View File

@ -7,9 +7,9 @@ from __future__ import absolute_import
# Import Python libs
import collections
import logging
import os
import sys
import traceback
import os
# Import salt libs
import salt.crypt

6
salt/modules/file.py
View File

@ -3315,9 +3315,11 @@ def get_managed(
return '', {}, 'Source file {0} not found'.format(source)
# if its a local file
elif urlparsed_source.scheme == 'file':
source_sum = get_hash(urlparsed_source.path)
file_sum = get_hash(urlparsed_source.path, form='sha256')
source_sum = {'hsum': file_sum, 'hash_type': 'sha256'}
elif source.startswith('/'):
source_sum = get_hash(source)
file_sum = get_hash(source, form='sha256')
source_sum = {'hsum': file_sum, 'hash_type': 'sha256'}
elif source_hash:
protos = ('salt', 'http', 'https', 'ftp', 'swift', 's3')
if _urlparse(source_hash).scheme in protos:

6
salt/modules/state.py
View File

@ -103,9 +103,9 @@ def _wait(jid):
def running(concurrent=False):
'''
Return a dict of 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.
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:

32
salt/modules/win_pkg.py
View File

@ -437,12 +437,28 @@ def genrepo(saltenv='base'):
def install(name=None, refresh=False, pkgs=None, saltenv='base', **kwargs):
'''
Install the passed package
Install the passed package from the winrepo
Return a dict containing the new package names and versions::
:param name: The name of the package to install
:type name: str or None
{'<package>': {'old': '<old-version>',
'new': '<new-version>'}}
:param bool refresh: Boolean value representing whether or not to refresh
the winrepo db
:param pkgs: A list of packages to install from a software repository.
All packages listed under ``pkgs`` will be installed via a single
command.
:type pkgs: list or None
:param str saltenv: The salt environment to use. Default is ``base``.
:param dict kwargs: Any additional argument that may be passed from the
state module. If they don't apply, they are ignored.
:return: Return a dict containing the new package names and versions::
{'<package>': {'old': '<old-version>',
'new': '<new-version>'}}
CLI Example:
@ -507,6 +523,9 @@ def install(name=None, refresh=False, pkgs=None, saltenv='base', **kwargs):
if not cached_pkg:
# It's not cached. Cache it, mate.
cached_pkg = __salt__['cp.cache_file'](installer, saltenv)
if not cached_pkg:
return 'Unable to cache file {0} from saltenv: {1}'\
.format(installer, saltenv)
if __salt__['cp.hash_file'](installer, saltenv) != \
__salt__['cp.hash_file'](cached_pkg):
cached_pkg = __salt__['cp.cache_file'](installer, saltenv)
@ -516,6 +535,9 @@ def install(name=None, refresh=False, pkgs=None, saltenv='base', **kwargs):
cached_pkg = cached_pkg.replace('/', '\\')
cache_path, _ = os.path.split(cached_pkg)
msiexec = pkginfo[version_num].get('msiexec')
allusers = pkginfo[version_num].get('allusers')
if allusers is None:
allusers = True
install_flags = '{0} {1}'.format(pkginfo[version_num]['install_flags'], options and options.get('extra_install_flags') or "")
cmd = []
@ -523,6 +545,8 @@ def install(name=None, refresh=False, pkgs=None, saltenv='base', **kwargs):
cmd.extend(['msiexec', '/i'])
cmd.append(cached_pkg)
cmd.extend(install_flags.split())
if msiexec and allusers:
cmd.append('ALLUSERS="1"')
__salt__['cmd.run'](cmd, cache_path, output_loglevel='trace', python_shell=False)

13
salt/returners/carbon_return.py
View File

@ -23,6 +23,17 @@ 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:
.. code-block:: yaml
@ -32,6 +43,7 @@ Carbon settings may also be configured as:
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
@ -208,6 +220,7 @@ def _send(saltdata, metric_base, opts):
host = opts.get('host')
port = opts.get('port')
skip = opts.get('skip')
metric_base_pattern = opts.get('carbon.metric_base_pattern')
if 'mode' in opts:
mode = opts.get('mode').lower()

8
salt/state.py
View File

@ -217,8 +217,8 @@ def format_log(ret):
new = chg[pkg]['new']
if not new and new not in (False, None):
new = 'absent'
msg += '{0} changed from {1} to ' \
'{2}\n'.format(pkg, old, new)
msg += '{0!r} changed from {1!r} to ' \
'{2!r}\n'.format(pkg, old, new)
if not msg:
msg = str(ret['changes'])
if ret['result'] is True or ret['result'] is None:
@ -257,9 +257,9 @@ class Compiler(object):
'''
Class used to compile and manage the High Data structure
'''
def __init__(self, opts):
def __init__(self, opts, renderers):
self.opts = opts
self.rend = salt.loader.render(self.opts, {})
self.rend = renderers
# We need __setstate__ and __getstate__ to avoid pickling errors since
# 'self.rend' contains a function reference which is not picklable.

390
salt/states/pkg.py
View File

@ -198,8 +198,6 @@ def _find_remove_targets(name=None,
__salt__.get('pkg.normalize_name', lambda pkgname: pkgname)
to_remove = {_normalize_name(name): version}
cver = cur_pkgs.get(name, [])
version_spec = False
# Find out which packages will be targeted in the call to pkg.remove
# Check current versions against specified versions
@ -346,7 +344,12 @@ def _find_install_targets(name=None,
# enforced. Takes extra time. Disable for improved performance
if not skip_suggestions:
# Perform platform-specific pre-flight checks
problems = _preflight_check(desired, **kwargs)
not_installed = dict([
(name, version)
for name, version in desired.items()
if not (name in cur_pkgs and version in (None, cur_pkgs[name]))
])
problems = _preflight_check(not_installed, **kwargs)
comments = []
if problems.get('no_suggest'):
comments.append(
@ -552,14 +555,61 @@ def installed(
Ensure that the package is installed, and that it is the correct version
(if specified).
name
: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.
fromrepo
:param str version:
Install a specific version of a package. This option is ignored if
either "pkgs" or "sources" is used. Currently, this option is supported
for the following pkg providers: :mod:`apt <salt.modules.aptpkg>`,
:mod:`ebuild <salt.modules.ebuild>`,
:mod:`pacman <salt.modules.pacman>`,
:mod:`yumpkg <salt.modules.yumpkg>`, and
:mod:`zypper <salt.modules.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.
.. code-block:: bash
# salt myminion pkg.latest_version httpd
myminion:
2.2.15-30.el6.centos
Also, while this function is not yet implemented for all pkg frontends,
:mod:`pkg.list_repo_pkgs <salt.modules.yumpkg.list_repo_pkgs>` will
show all versions available in the various repositories for a given
package, irrespective of whether or not it is installed.
.. code-block:: bash
# 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.
:param bool refresh:
Update the repo database of available packages prior to installing the
requested package.
:param str fromrepo:
Specify a repository from which to install
.. note::
@ -613,68 +663,101 @@ def installed(
**4:0.8.10-0ubuntu0.12.04.1** either ``precise-updates`` or
``precise-security`` could be used for the ``fromrepo`` value.
skip_verify
:param bool skip_verify:
Skip the GPG verification check for the package to be installed
skip_suggestions
:param bool skip_suggestions:
Force strict package naming. Disables lookup of package alternatives.
.. versionadded:: 2014.1.1
version
Install a specific version of a package. This option is ignored if
either "pkgs" or "sources" is used. Currently, this option is supported
for the following pkg providers: :mod:`apt <salt.modules.aptpkg>`,
: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.
Example:
.. code-block:: yaml
mypkgs:
pkg.installed:
- pkgs:
- foo
- bar
- baz
- hold: True
``NOTE:`` For :mod:`apt <salt.modules.aptpkg>`,
:mod:`ebuild <salt.modules.ebuild>`,
:mod:`pacman <salt.modules.pacman>`,
:mod:`yumpkg <salt.modules.yumpkg>`, and
:mod:`zypper <salt.modules.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.
:mod:`pacman <salt.modules.pacman>`, :mod:`yumpkg <salt.modules.yumpkg>`,
and :mod:`zypper <salt.modules.zypper>`, version numbers can be specified
in the ``pkgs`` argument. For example:
.. code-block:: bash
.. code-block:: yaml
# salt myminion pkg.latest_version httpd
myminion:
2.2.15-30.el6.centos
mypkgs:
pkg.installed:
- pkgs:
- foo
- bar: 1.2.3-4
- baz
Also, while this function is not yet implemented for all pkg frontends,
:mod:`pkg.list_repo_pkgs <salt.modules.yumpkg.list_repo_pkgs>` will
show all versions available in the various repositories for a given
package, irrespective of whether or not it is installed.
Additionally, :mod:`ebuild <salt.modules.ebuild>`,
:mod:`pacman <salt.modules.pacman>` and
:mod:`zypper <salt.modules.zypper>` support the ``<``, ``<=``, ``>=``, and
``>`` operators for more control over what versions will be installed. For
.. code-block:: bash
Example:
# salt myminion pkg.list_repo_pkgs httpd
myminion:
----------
base:
|_
----------
httpd:
2.2.15-29.el6.centos
updates:
|_
----------
httpd:
2.2.15-30.el6.centos
.. code-block:: yaml
The version strings returned by either of these functions can be used
as version specifiers in pkg states.
mypkgs:
pkg.installed:
- pkgs:
- foo
- bar: '>=1.2.3-4'
- baz
refresh
Update the repo database of available packages prior to installing the
requested package.
``NOTE:`` When using comparison operators, the expression must be enclosed
in quotes to avoid a YAML render error.
hold
Force the package to be held at the current installed version.
Currently works with YUM & APT-based systems.
With :mod:`ebuild <salt.modules.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.
.. versionadded:: 2014.7.0
For example:
allow_updates
.. code-block:: yaml
mypkgs:
pkg.installed:
- pkgs:
- foo: '~'
- bar: '~>=1.2:slot::overlay[use,-otheruse]'
- baz
**Multiple Package Installation Options: (not supported in Windows or
pkgng)**
: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.
.. code-block:: yaml
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
: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
@ -682,20 +765,22 @@ def installed(
.. versionadded:: 2014.7.0
Example:
Example:
.. code-block:: yaml
.. code-block:: yaml
httpd:
pkg.installed:
- fromrepo: mycustomrepo
- skip_verify: True
- skip_suggestions: True
- version: 2.0.6~ubuntu3
- refresh: True
- hold: False
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:
pkg_verify
.. versionadded:: 2014.7.0
For requested packages that are already installed and would not be
@ -706,27 +791,27 @@ def installed(
below). Currently, this option is supported for the following pkg
providers: :mod:`yumpkg <salt.modules.yumpkg>`.
Examples:
Examples:
.. code-block:: yaml
.. code-block:: yaml
httpd:
pkg.installed:
- version: 2.2.15-30.el6.centos
- pkg_verify: True
httpd:
pkg.installed:
- version: 2.2.15-30.el6.centos
- pkg_verify: True
.. code-block:: yaml
.. code-block:: yaml
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]
normalize : True
: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
@ -736,133 +821,64 @@ def installed(
.. versionadded:: 2014.7.0
Example:
Example:
.. code-block:: yaml
.. code-block:: yaml
gpfs.gplbin-2.6.32-279.31.1.el6.x86_64:
pkg.installed:
- normalize: False
gpfs.gplbin-2.6.32-279.31.1.el6.x86_64:
pkg.installed:
- normalize: False
**Multiple Package Installation Options: (not supported in Windows or
pkgng)**
:param kwargs:
These are specific to each OS. If it does not apply to the execution
module for your OS, it is ignored.
pkgs
A list of packages to install from a software repository. All packages
listed under ``pkgs`` will be installed via a single command.
:param bool hold:
Force the package to be held at the current installed version.
Currently works with YUM & APT based systems.
Example:
.. versionadded:: 2014.7.0
.. code-block:: yaml
:param list names:
A list of packages to install from a software repository. Each package
will be installed individually by the package manager.
mypkgs:
pkg.installed:
- pkgs:
- foo
- bar
- baz
- hold: True
.. warning::
``NOTE:`` For :mod:`apt <salt.modules.aptpkg>`,
:mod:`ebuild <salt.modules.ebuild>`,
:mod:`pacman <salt.modules.pacman>`, :mod:`yumpkg <salt.modules.yumpkg>`,
and :mod:`zypper <salt.modules.zypper>`, version numbers can be specified
in the ``pkgs`` argument. For example:
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.
.. code-block:: yaml
:param bool install_recommends:
Whether to install the packages marked as recommended. Default is
``True``. Currently only works with APT-based systems.
mypkgs:
pkg.installed:
- pkgs:
- foo
- bar: 1.2.3-4
- baz
.. versionadded:: 2015.5.0
Additionally, :mod:`ebuild <salt.modules.ebuild>`,
:mod:`pacman <salt.modules.pacman>` and
:mod:`zypper <salt.modules.zypper>` support the ``<``, ``<=``, ``>=``, and
``>`` operators for more control over what versions will be installed. For
example:
.. code-block:: yaml
.. code-block:: yaml
httpd:
pkg.installed:
- install_recommends: False
mypkgs:
pkg.installed:
- pkgs:
- foo
- bar: '>=1.2.3-4'
- baz
:param bool only_upgrade:
Only upgrade the packages, if they are already installed. Default is
``False``. Currently only works with APT-based systems.
``NOTE:`` When using comparison operators, the expression must be enclosed
in quotes to avoid a YAML render error.
.. versionadded:: 2015.5.0
With :mod:`ebuild <salt.modules.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:
.. code-block:: yaml
.. code-block:: yaml
httpd:
pkg.installed:
- only_upgrade: True
mypkgs:
pkg.installed:
- pkgs:
- foo: '~'
- bar: '~>=1.2:slot::overlay[use,-otheruse]'
- baz
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.
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.
.. code-block:: yaml
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
install_recommends
Whether to install the packages marked as recommended. Default is
``True``. Currently only works with APT-based systems.
.. versionadded:: 2015.5.0
.. code-block:: yaml
httpd:
pkg.installed:
- install_recommends: False
only_upgrade
Only upgrade the packages, if they are already installed. Default is
``False``. Currently only works with APT-based systems.
.. versionadded:: 2015.5.0
.. code-block:: yaml
httpd:
pkg.installed:
- only_upgrade: True
:return:
A dictionary containing the state of the software installation
:rtype dict:
'''
if isinstance(pkgs, list) and len(pkgs) == 0:

2
salt/states/schedule.py
View File

@ -62,7 +62,7 @@ Management of the Salt scheduler
- args:
- httpd
- kwargs:
test: True
test: True
- when:
- Monday 5:00pm
- Tuesday 3:00pm

5
salt/utils/reactor.py
View File

@ -30,11 +30,10 @@ class Reactor(multiprocessing.Process, salt.state.Compiler):
'''
def __init__(self, opts):
multiprocessing.Process.__init__(self)
salt.state.Compiler.__init__(self, opts)
local_minion_opts = self.opts.copy()
local_minion_opts = opts.copy()
local_minion_opts['file_client'] = 'local'
self.minion = salt.minion.MasterMinion(local_minion_opts)
salt.state.Compiler.__init__(self, opts, self.minion.rend)
def render_reaction(self, glob_ref, tag, data):
'''

1
salt/version.py
View File

@ -552,6 +552,7 @@ def dependency_information(include_salt_cloud=False):
('ZMQ', 'zmq', 'zmq_version'),
('Mako', 'mako', '__version__'),
('Tornado', 'tornado', 'version'),
('timelib', 'timelib', 'version'),
]
if include_salt_cloud: