neulab/tldr huggingface dataset:
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:
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:
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.
https://pypi.python.org/packages/source/s/salt/salt-0.9.4.tar.gz
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.
/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.
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.
vim: pkg: - installed - order: 1
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.
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 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 Black Duck Open Hub (https://www.openhub.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 (https://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:
• _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: 'L@foo.domain.com,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:
https://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 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.
lookup_jid When jobs are executed the return data is sent back to the master and cached.  By default 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.
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.
# 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/ubuntu/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:
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:
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
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:
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.
Upcoming Release Salt 3004 Release Notes - Codename Silicon New Features Transactional System Support (MicroOS) A transactional system, like MicroOS, can present some challenges when the user decided to manage it via Salt.
Salt 3004 (Silicon) support this type of system via two new modules (transactional_update and rebootmgr) and a new executor (transactional_update).
The new modules will provide all the low level API for interacting with transactional systems, like defining a mantenance window where the system is free to reboot and activate the new state, or install new software in a new transaction.  It will also provide hight level of abstractions that will allows us to execute Salt module functions or applying states inside new transactions.
The execution module will help us to treat the transactional system transparently (like the traditional ones), using a mechanism that will delegate some Salt modules execution into the new transactional_update module.