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
.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']
loosing 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.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.Modules may now be packaged via entry-points in setuptools. See
external module packaging </topics/tutorials/packaging_modules
tutorial
for more information.
The 2016.3 release introduces the new Thorium Reactor. This reactor is an experimental new feature that implements a flow programing 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.
The following list contains a link to the new modules added in this release.
Many additional modules were updated with new functionality, these changes are
indicated with New in version Boron
throughout the documentation.
beacons.adb
beacons.memusage
beacons.network_settings
beacons.proxy_example
beacons.salt_proxy
modules.bcache
modules.boto_cloudtrail
modules.boto_datapipeline
modules.boto_iot
modules.boto_lambda
modules.chronos
modules.cytest
modules.dockercompose
modules.dsc
modules.ethtool
modules.github
modules.iwtools
modules.jenkins
modules.linux_ip
modules.mac_shadow
modules.mac_softwareupdate
modules.marathon
modules.minion
modules.openvswitch
modules.opkg
modules.philips_hue
modules.pushbullet
modules.restartcheck
modules.s6
modules.salt_proxy
modules.ssh_package
modules.ssh_service
modules.sysfs
modules.vboxmanage
modules.win_dsc
modules.win_iis
modules.win_task
modules.zabbix
proxy.chronos
proxy.junos
proxy.marathon
proxy.phillips_hue
proxy.ssh_sample
states.apache_conf
states.apache_site
states.boto_cloudtrail
states.boto_datapipeline
states.boto_iot
states.boto_lamda
states.chocolatey
states.chronos_job
states.firewall
states.github
states.gpg
states.grafana_dashboard
states.grafana_datasource
states.infoblox
states.jenkins
states.marathon_app
states.openvswitch_bridge
states.openvswitch_port
states.postgres_cluster
states.salt_proxy
states.virt
states.zabbix_host
states.zabbix_hostgroup
states.zabbix_user
states.zabbix_usergroup
issue 25816: Fixed an issue that caused the Windows installer to not stop the old minion processes, resulting in a failed installation.