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.adbbeacons.memusagebeacons.network_settingsbeacons.proxy_examplebeacons.salt_proxymodules.bcachemodules.boto_cloudtrailmodules.boto_datapipelinemodules.boto_iotmodules.boto_lambdamodules.chronosmodules.cytestmodules.dockercomposemodules.dscmodules.ethtoolmodules.githubmodules.iwtoolsmodules.jenkinsmodules.linux_ipmodules.mac_shadowmodules.mac_softwareupdatemodules.marathonmodules.minionmodules.openvswitchmodules.opkgmodules.philips_huemodules.pushbulletmodules.restartcheckmodules.s6modules.salt_proxymodules.ssh_packagemodules.ssh_servicemodules.sysfsmodules.vboxmanagemodules.win_dscmodules.win_iismodules.win_taskmodules.zabbixproxy.chronosproxy.junosproxy.marathonproxy.phillips_hueproxy.ssh_samplestates.apache_confstates.apache_sitestates.boto_cloudtrailstates.boto_datapipelinestates.boto_iotstates.boto_lamdastates.chocolateystates.chronos_jobstates.firewallstates.githubstates.gpgstates.grafana_dashboardstates.grafana_datasourcestates.infobloxstates.jenkinsstates.marathon_appstates.openvswitch_bridgestates.openvswitch_portstates.postgres_clusterstates.salt_proxystates.virtstates.zabbix_hoststates.zabbix_hostgroupstates.zabbix_userstates.zabbix_usergroupissue 25816: Fixed an issue that caused the Windows installer to not stop the old minion processes, resulting in a failed installation.