2016-07-21 19:05:39 +02:00
|
|
|
# $NetBSD: Makefile,v 1.41 2016/07/21 17:05:39 jperkin Exp $
|
2012-01-21 21:26:58 +01:00
|
|
|
|
2016-07-21 19:05:39 +02:00
|
|
|
DISTNAME= salt-2016.3.1
|
2012-01-21 21:26:58 +01:00
|
|
|
CATEGORIES= sysutils
|
2015-12-11 01:27:06 +01:00
|
|
|
MASTER_SITES= ${MASTER_SITE_PYPI:=s/salt/}
|
2012-01-21 21:26:58 +01:00
|
|
|
|
|
|
|
|
MAINTAINER= pkgsrc-users@NetBSD.org
|
2012-02-12 14:40:44 +01:00
|
|
|
HOMEPAGE= http://saltstack.org/
|
2012-01-21 21:26:58 +01:00
|
|
|
COMMENT= Remote execution and configuration management system
|
|
|
|
|
LICENSE= apache-2.0
|
|
|
|
|
|
2014-01-25 11:29:56 +01:00
|
|
|
DEPENDS+= zeromq>=2.1.9:../../net/zeromq
|
|
|
|
|
DEPENDS+= ${PYPKGPREFIX}-zmq>=2.1.9:../../net/py-zmq
|
|
|
|
|
DEPENDS+= ${PYPKGPREFIX}-m2crypto-[0-9]*:../../security/py-m2crypto
|
|
|
|
|
DEPENDS+= ${PYPKGPREFIX}-crypto-[0-9]*:../../security/py-crypto
|
|
|
|
|
DEPENDS+= ${PYPKGPREFIX}-msgpack-[0-9]*:../../devel/py-msgpack
|
|
|
|
|
DEPENDS+= ${PYPKGPREFIX}-yaml-[0-9]*:../../textproc/py-yaml
|
|
|
|
|
DEPENDS+= ${PYPKGPREFIX}-jinja2-[0-9]*:../../textproc/py-jinja2
|
2014-04-17 18:33:47 +02:00
|
|
|
DEPENDS+= ${PYPKGPREFIX}-apache-libcloud>=0.14.1:../../net/py-apache-libcloud
|
2015-02-23 14:58:13 +01:00
|
|
|
DEPENDS+= ${PYPKGPREFIX}-requests>=2.5.0:../../devel/py-requests
|
2015-12-04 10:13:33 +01:00
|
|
|
DEPENDS+= ${PYPKGPREFIX}-tornado>=4.3:../../www/py-tornado
|
2014-01-25 11:29:56 +01:00
|
|
|
|
2014-03-30 14:31:17 +02:00
|
|
|
BUILD_DEFS+= VARBASE
|
|
|
|
|
|
2016-07-09 15:03:30 +02:00
|
|
|
PYTHON_VERSIONS_INCOMPATIBLE= 34 35 # py-m2crypto
|
2014-01-25 11:29:56 +01:00
|
|
|
|
2014-03-30 14:31:17 +02:00
|
|
|
PYSETUPINSTALLARGS+= --salt-root-dir=${PREFIX}
|
|
|
|
|
PYSETUPINSTALLARGS+= --salt-config-dir=${PKG_SYSCONFDIR}
|
|
|
|
|
PYSETUPINSTALLARGS+= --salt-cache-dir=${VARBASE}/cache/salt
|
2015-12-07 22:51:53 +01:00
|
|
|
PYSETUPINSTALLARGS+= --salt-sock-dir=${VARBASE}/run/salt
|
2014-03-30 14:31:17 +02:00
|
|
|
PYSETUPINSTALLARGS+= --salt-base-file-roots-dir=${PKG_SYSCONFDIR}/states
|
|
|
|
|
PYSETUPINSTALLARGS+= --salt-base-pillar-roots-dir=${PKG_SYSCONFDIR}/pillar
|
|
|
|
|
PYSETUPINSTALLARGS+= --salt-base-master-roots-dir=${PKG_SYSCONFDIR}/salt-master
|
|
|
|
|
PYSETUPINSTALLARGS+= --salt-logs-dir=${VARBASE}/log/salt
|
|
|
|
|
PYSETUPINSTALLARGS+= --salt-pidfile-dir=${VARBASE}/run
|
|
|
|
|
|
2016-07-21 19:05:39 +02:00
|
|
|
REPLACE_PYTHON= *.py */*.py */*/*.py
|
|
|
|
|
REPLACE_SH= salt/templates/git/ssh-id-wrapper
|
. Fixed rc.d script by adding comment_interpreter
. Updated salt to version 0.15.0
From SaltStack website:
Salt 0.15.0 comes with many smaller features and a few larger ones.
The Salt Mine
First there was the peer system, allowing for commands to be executed from a
minion to other minions to gather data live. Then there was the external job
cache for storing and accessing long term data. Now the middle ground is being
filled in with the Salt Mine. The Salt Mine is a system used to execute
functions on a regular basis on minions and then store only the most recent
data from the functions on the master, then the data is looked up via targets.
The mine caches data that is public to all minions, so when a minion posts
data to the mine all other minions can see it.
IPV6 Support
0.13.0 saw the addition of initial IPV6 support but errors were encountered
and it needed to be stripped out. This time the code covers more cases and
must be explicitly enabled. But the support is much more extensive than before.
Copy Files From Minions to the Master
Minions have long been able to copy files down from the master file server,
but until now files could not be easily copied from the minion up to the
master.
A new function called cp.push can push files from the minions up to the master
server. The uploaded files are then cached on the master in the master
cachedir for each minon.
Better Template Debugging
Template errors have long been a burden when writing states and pillar. 0.15.0
will now send the compiled template data to the debug log, this makes tracking
down the intermittent stage templates much easier. So running state.sls or
state.highstate with -l debug will now print out the rendered templates in the
debug information.
State Event Firing
The state system is now more closely tied to the master's event bus. Now when
a state fails the failure will be fired on the master event bus so that the
reactor can respond to it.
Major Syndic Updates
The Syndic system has been basically re-written. Now it runs in a completely
asynchronous way and functions primarily as an event broker. This means that
the events fired on the syndic are now pushed up to the higher level master
instead of the old method used which waited for the client libraries to return.
This makes the syndic much more accurate and powerful, it also means that all
events fired on the syndic master make it up the pipe as well making a reactor
on the higher level master able to react to minions further downstream.
Peer System Updates
The Peer System has been updated to run using the client libraries instead of
firing directly over the publish bus. This makes the peer system much more
consistent and reliable.
Minion Key Revocation
In the past when a minion was decommissioned the key needed to be manually
deleted on the master, but now a function on the minion can be used to revoke
the calling minion's key:
salt-call saltutil.revoke_auth
Function Return Codes
Functions can now be assigned numeric return codes to determine if the
function executed successfully. While not all functions have been given return
codes, many have and it is an ongoing effort to fill out all functions that
might return a non-zero return code.
Functions in Overstate
The overstate system was originally created to just manage the execution of
states, but with the addition of return codes to functions, requisite logic
can now be used with respect to the overstate. This means that an overstate
stage can now run single functions instead of just state executions.
Pillar Error Reporting
Previously if errors surfaced in pillar, then the pillar would consist of only
and empty dict. Now all data that was successfully rendered stays in pillar
and the render error is also made available. If errors are found in the
pillar, states will refuse to run.
Using Cached State Data
Sometimes states are executed purely to maintain a specific state rather than
to update states with new configs. This is grounds for the new cached state
system. By adding cache=True to a state call the state will not be generated
fresh from the master but the last state data to be generated will be used.
If no previous state data is available then fresh data will be generated.
Monitoring States
The new monitoring states system has been started. This is very young but
allows for states to be used to configure monitoring routines. So far only one
monitoring state is available, the disk.status state. As more capabilities are
added to Salt UI the monitoring capabilities of Salt will continue to be
expanded.
2013-05-05 14:26:23 +02:00
|
|
|
|
2016-02-16 01:00:08 +01:00
|
|
|
RCD_SCRIPTS+= salt_master salt_minion salt_syndic
|
2015-07-24 12:24:27 +02:00
|
|
|
SMF_INSTANCES= master minion
|
. Fixed rc.d script by adding comment_interpreter
. Updated salt to version 0.15.0
From SaltStack website:
Salt 0.15.0 comes with many smaller features and a few larger ones.
The Salt Mine
First there was the peer system, allowing for commands to be executed from a
minion to other minions to gather data live. Then there was the external job
cache for storing and accessing long term data. Now the middle ground is being
filled in with the Salt Mine. The Salt Mine is a system used to execute
functions on a regular basis on minions and then store only the most recent
data from the functions on the master, then the data is looked up via targets.
The mine caches data that is public to all minions, so when a minion posts
data to the mine all other minions can see it.
IPV6 Support
0.13.0 saw the addition of initial IPV6 support but errors were encountered
and it needed to be stripped out. This time the code covers more cases and
must be explicitly enabled. But the support is much more extensive than before.
Copy Files From Minions to the Master
Minions have long been able to copy files down from the master file server,
but until now files could not be easily copied from the minion up to the
master.
A new function called cp.push can push files from the minions up to the master
server. The uploaded files are then cached on the master in the master
cachedir for each minon.
Better Template Debugging
Template errors have long been a burden when writing states and pillar. 0.15.0
will now send the compiled template data to the debug log, this makes tracking
down the intermittent stage templates much easier. So running state.sls or
state.highstate with -l debug will now print out the rendered templates in the
debug information.
State Event Firing
The state system is now more closely tied to the master's event bus. Now when
a state fails the failure will be fired on the master event bus so that the
reactor can respond to it.
Major Syndic Updates
The Syndic system has been basically re-written. Now it runs in a completely
asynchronous way and functions primarily as an event broker. This means that
the events fired on the syndic are now pushed up to the higher level master
instead of the old method used which waited for the client libraries to return.
This makes the syndic much more accurate and powerful, it also means that all
events fired on the syndic master make it up the pipe as well making a reactor
on the higher level master able to react to minions further downstream.
Peer System Updates
The Peer System has been updated to run using the client libraries instead of
firing directly over the publish bus. This makes the peer system much more
consistent and reliable.
Minion Key Revocation
In the past when a minion was decommissioned the key needed to be manually
deleted on the master, but now a function on the minion can be used to revoke
the calling minion's key:
salt-call saltutil.revoke_auth
Function Return Codes
Functions can now be assigned numeric return codes to determine if the
function executed successfully. While not all functions have been given return
codes, many have and it is an ongoing effort to fill out all functions that
might return a non-zero return code.
Functions in Overstate
The overstate system was originally created to just manage the execution of
states, but with the addition of return codes to functions, requisite logic
can now be used with respect to the overstate. This means that an overstate
stage can now run single functions instead of just state executions.
Pillar Error Reporting
Previously if errors surfaced in pillar, then the pillar would consist of only
and empty dict. Now all data that was successfully rendered stays in pillar
and the render error is also made available. If errors are found in the
pillar, states will refuse to run.
Using Cached State Data
Sometimes states are executed purely to maintain a specific state rather than
to update states with new configs. This is grounds for the new cached state
system. By adding cache=True to a state call the state will not be generated
fresh from the master but the last state data to be generated will be used.
If no previous state data is available then fresh data will be generated.
Monitoring States
The new monitoring states system has been started. This is very young but
allows for states to be used to configure monitoring routines. So far only one
monitoring state is available, the disk.status state. As more capabilities are
added to Salt UI the monitoring capabilities of Salt will continue to be
expanded.
2013-05-05 14:26:23 +02:00
|
|
|
FILES_SUBST+= PYTHON=${PYTHONBIN:Q}
|
2012-01-21 21:26:58 +01:00
|
|
|
|
. Fixed rc.d script by adding comment_interpreter
. Updated salt to version 0.15.0
From SaltStack website:
Salt 0.15.0 comes with many smaller features and a few larger ones.
The Salt Mine
First there was the peer system, allowing for commands to be executed from a
minion to other minions to gather data live. Then there was the external job
cache for storing and accessing long term data. Now the middle ground is being
filled in with the Salt Mine. The Salt Mine is a system used to execute
functions on a regular basis on minions and then store only the most recent
data from the functions on the master, then the data is looked up via targets.
The mine caches data that is public to all minions, so when a minion posts
data to the mine all other minions can see it.
IPV6 Support
0.13.0 saw the addition of initial IPV6 support but errors were encountered
and it needed to be stripped out. This time the code covers more cases and
must be explicitly enabled. But the support is much more extensive than before.
Copy Files From Minions to the Master
Minions have long been able to copy files down from the master file server,
but until now files could not be easily copied from the minion up to the
master.
A new function called cp.push can push files from the minions up to the master
server. The uploaded files are then cached on the master in the master
cachedir for each minon.
Better Template Debugging
Template errors have long been a burden when writing states and pillar. 0.15.0
will now send the compiled template data to the debug log, this makes tracking
down the intermittent stage templates much easier. So running state.sls or
state.highstate with -l debug will now print out the rendered templates in the
debug information.
State Event Firing
The state system is now more closely tied to the master's event bus. Now when
a state fails the failure will be fired on the master event bus so that the
reactor can respond to it.
Major Syndic Updates
The Syndic system has been basically re-written. Now it runs in a completely
asynchronous way and functions primarily as an event broker. This means that
the events fired on the syndic are now pushed up to the higher level master
instead of the old method used which waited for the client libraries to return.
This makes the syndic much more accurate and powerful, it also means that all
events fired on the syndic master make it up the pipe as well making a reactor
on the higher level master able to react to minions further downstream.
Peer System Updates
The Peer System has been updated to run using the client libraries instead of
firing directly over the publish bus. This makes the peer system much more
consistent and reliable.
Minion Key Revocation
In the past when a minion was decommissioned the key needed to be manually
deleted on the master, but now a function on the minion can be used to revoke
the calling minion's key:
salt-call saltutil.revoke_auth
Function Return Codes
Functions can now be assigned numeric return codes to determine if the
function executed successfully. While not all functions have been given return
codes, many have and it is an ongoing effort to fill out all functions that
might return a non-zero return code.
Functions in Overstate
The overstate system was originally created to just manage the execution of
states, but with the addition of return codes to functions, requisite logic
can now be used with respect to the overstate. This means that an overstate
stage can now run single functions instead of just state executions.
Pillar Error Reporting
Previously if errors surfaced in pillar, then the pillar would consist of only
and empty dict. Now all data that was successfully rendered stays in pillar
and the render error is also made available. If errors are found in the
pillar, states will refuse to run.
Using Cached State Data
Sometimes states are executed purely to maintain a specific state rather than
to update states with new configs. This is grounds for the new cached state
system. By adding cache=True to a state call the state will not be generated
fresh from the master but the last state data to be generated will be used.
If no previous state data is available then fresh data will be generated.
Monitoring States
The new monitoring states system has been started. This is very young but
allows for states to be used to configure monitoring routines. So far only one
monitoring state is available, the disk.status state. As more capabilities are
added to Salt UI the monitoring capabilities of Salt will continue to be
expanded.
2013-05-05 14:26:23 +02:00
|
|
|
PKG_SYSCONFSUBDIR= salt
|
2012-01-21 21:26:58 +01:00
|
|
|
|
. Fixed rc.d script by adding comment_interpreter
. Updated salt to version 0.15.0
From SaltStack website:
Salt 0.15.0 comes with many smaller features and a few larger ones.
The Salt Mine
First there was the peer system, allowing for commands to be executed from a
minion to other minions to gather data live. Then there was the external job
cache for storing and accessing long term data. Now the middle ground is being
filled in with the Salt Mine. The Salt Mine is a system used to execute
functions on a regular basis on minions and then store only the most recent
data from the functions on the master, then the data is looked up via targets.
The mine caches data that is public to all minions, so when a minion posts
data to the mine all other minions can see it.
IPV6 Support
0.13.0 saw the addition of initial IPV6 support but errors were encountered
and it needed to be stripped out. This time the code covers more cases and
must be explicitly enabled. But the support is much more extensive than before.
Copy Files From Minions to the Master
Minions have long been able to copy files down from the master file server,
but until now files could not be easily copied from the minion up to the
master.
A new function called cp.push can push files from the minions up to the master
server. The uploaded files are then cached on the master in the master
cachedir for each minon.
Better Template Debugging
Template errors have long been a burden when writing states and pillar. 0.15.0
will now send the compiled template data to the debug log, this makes tracking
down the intermittent stage templates much easier. So running state.sls or
state.highstate with -l debug will now print out the rendered templates in the
debug information.
State Event Firing
The state system is now more closely tied to the master's event bus. Now when
a state fails the failure will be fired on the master event bus so that the
reactor can respond to it.
Major Syndic Updates
The Syndic system has been basically re-written. Now it runs in a completely
asynchronous way and functions primarily as an event broker. This means that
the events fired on the syndic are now pushed up to the higher level master
instead of the old method used which waited for the client libraries to return.
This makes the syndic much more accurate and powerful, it also means that all
events fired on the syndic master make it up the pipe as well making a reactor
on the higher level master able to react to minions further downstream.
Peer System Updates
The Peer System has been updated to run using the client libraries instead of
firing directly over the publish bus. This makes the peer system much more
consistent and reliable.
Minion Key Revocation
In the past when a minion was decommissioned the key needed to be manually
deleted on the master, but now a function on the minion can be used to revoke
the calling minion's key:
salt-call saltutil.revoke_auth
Function Return Codes
Functions can now be assigned numeric return codes to determine if the
function executed successfully. While not all functions have been given return
codes, many have and it is an ongoing effort to fill out all functions that
might return a non-zero return code.
Functions in Overstate
The overstate system was originally created to just manage the execution of
states, but with the addition of return codes to functions, requisite logic
can now be used with respect to the overstate. This means that an overstate
stage can now run single functions instead of just state executions.
Pillar Error Reporting
Previously if errors surfaced in pillar, then the pillar would consist of only
and empty dict. Now all data that was successfully rendered stays in pillar
and the render error is also made available. If errors are found in the
pillar, states will refuse to run.
Using Cached State Data
Sometimes states are executed purely to maintain a specific state rather than
to update states with new configs. This is grounds for the new cached state
system. By adding cache=True to a state call the state will not be generated
fresh from the master but the last state data to be generated will be used.
If no previous state data is available then fresh data will be generated.
Monitoring States
The new monitoring states system has been started. This is very young but
allows for states to be used to configure monitoring routines. So far only one
monitoring state is available, the disk.status state. As more capabilities are
added to Salt UI the monitoring capabilities of Salt will continue to be
expanded.
2013-05-05 14:26:23 +02:00
|
|
|
EGDIR= ${PREFIX}/share/examples/salt
|
|
|
|
|
INSTALLATION_DIRS+= ${EGDIR}
|
|
|
|
|
CONF_FILES+= ${EGDIR}/master ${PKG_SYSCONFDIR}/master
|
|
|
|
|
CONF_FILES+= ${EGDIR}/minion ${PKG_SYSCONFDIR}/minion
|
2012-01-21 21:26:58 +01:00
|
|
|
|
2014-03-30 14:31:17 +02:00
|
|
|
OWN_DIRS+= ${PKG_SYSCONFDIR}/states ${PKG_SYSCONFDIR}/pillar
|
|
|
|
|
OWN_DIRS+= ${PKG_SYSCONFDIR}/salt-master
|
|
|
|
|
OWN_DIRS+= ${VARBASE}/cache/salt ${VARBASE}/run/salt
|
|
|
|
|
OWN_DIRS+= ${VARBASE}/log/salt
|
|
|
|
|
|
|
|
|
|
SUBST_CLASSES+= fix-paths
|
|
|
|
|
SUBST_STAGE.fix-paths= pre-configure
|
|
|
|
|
SUBST_MESSAGE.fix-paths=Fixing hardcoded paths
|
|
|
|
|
SUBST_FILES.fix-paths= conf/*
|
2015-02-23 14:58:13 +01:00
|
|
|
SUBST_FILES.fix-paths+= doc/man/* salt/modules/munin.py setup.py
|
2015-12-11 01:27:06 +01:00
|
|
|
SUBST_FILES.fix-paths+= salt/utils/rsax931.py salt/grains/core.py
|
2014-03-30 14:31:17 +02:00
|
|
|
SUBST_SED.fix-paths= -e 's,/etc/salt,${PKG_SYSCONFDIR},g'
|
|
|
|
|
SUBST_SED.fix-paths+= -e 's,/srv/salt,${PKG_SYSCONFDIR}/states,g'
|
|
|
|
|
SUBST_SED.fix-paths+= -e 's,/srv/pillar,${PKG_SYSCONFDIR}/pillar,g'
|
2014-05-06 12:57:48 +02:00
|
|
|
SUBST_SED.fix-paths+= -e 's,/etc/munin,${PKG_SYSCONFBASEDIR}/munin,g'
|
2016-04-21 13:36:03 +02:00
|
|
|
SUBST_SED.fix-paths+= -e 's,share/man,${PKGMANDIR},g'
|
2015-12-11 01:27:06 +01:00
|
|
|
SUBST_SED.fix-paths+= -e 's,/opt/local/lib,${PREFIX}/lib,g'
|
|
|
|
|
SUBST_SED.fix-paths+= -e 's,/opt/local/etc,${PKG_SYSCONFBASEDIR},g'
|
2014-03-30 14:31:17 +02:00
|
|
|
|
Update salt from 0.9.5 to 0.10.5.
The new DESCR is taken from the "Introduction to Salt" at
<http://docs.saltstack.org/en/v0.10.5/topics/index.html>.
Here's a copy of the introductory paragraphs from the release notes
for all the intervening versions:
Salt 0.9.6 Release Notes
========================
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.
Salt 0.9.7 Release Notes
========================
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.
Salt 0.9.8 Release Notes
========================
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.
Salt 0.9.9 Release Notes
========================
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.
Salt 0.10.0 Release Notes
=========================
0.10.0 has arrived! This release comes with MANY bug fixes, and new
capabilities which greatly enhance performance and reliability. This
release is primarily a bug fix release with many new tests and many repaired
bugs. This release also introduces a few new key features which were brought
in primarily to repair bugs and some limitations found in some of the
components of the original architecture.
Salt 0.10.2 Release Notes
=========================
0.10.2 is out! This release comes with enhancements to the pillar interface,
cleaner ways to access the salt-call capabilities in the API, minion data
caching and the event system has been added to salt minions.
There have also been updates to the zeromq functions, many more tests
(thanks to sponsors, the code sprint and many contributors) and a swath
of bug fixes.
Salt 0.10.3 Release Notes
=========================
The latest taste of Salt has come, this release has many fixes and feature
additions. Modifications have been made to make ZeroMQ connections more
reliable, the begining of the ACL system is in place, a new command line
parsing system has been added, dynamic module distribution has become more
environment aware, the new `master_finger` option and many more!
Salt 0.10.4 Release Notes
=========================
Salt 0.10.4 is a monumental release for the Salt team, with two new module
systems, many additions to allow granular access to Salt, improved platform
support and much more.
This release is also exciting because we have been able to shorten the release
cycle back to under a month. We are working hard to keep up the aggressive pace
and look forward to having releases happen more frequently!
This release also includes a serious security fix and all users are very
strongly recommended to upgrade. As usual, upgrade the master first, and then
the minion to ensure that the process is smooth.
Salt 0.10.5 Release Notes
=========================
Salt 0.10.5 is ready, and comes with some great new features. A few more
interfaces have been modularized, like the outputter system. The job cache
system has been made more powerful and can now store and retrieve jobs archived
in external databases. The returner system has been extended to allow minions
to easily retrieve data from a returner interface.
As usual, this is an exciting release, with many noteworthy additions!
2012-12-06 09:01:21 +01:00
|
|
|
post-install:
|
2013-04-28 11:46:24 +02:00
|
|
|
${INSTALL_DATA} ${WRKSRC}/conf/master ${DESTDIR}${EGDIR}/
|
|
|
|
|
${INSTALL_DATA} ${WRKSRC}/conf/minion ${DESTDIR}${EGDIR}/
|
Update salt from 0.9.5 to 0.10.5.
The new DESCR is taken from the "Introduction to Salt" at
<http://docs.saltstack.org/en/v0.10.5/topics/index.html>.
Here's a copy of the introductory paragraphs from the release notes
for all the intervening versions:
Salt 0.9.6 Release Notes
========================
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.
Salt 0.9.7 Release Notes
========================
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.
Salt 0.9.8 Release Notes
========================
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.
Salt 0.9.9 Release Notes
========================
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.
Salt 0.10.0 Release Notes
=========================
0.10.0 has arrived! This release comes with MANY bug fixes, and new
capabilities which greatly enhance performance and reliability. This
release is primarily a bug fix release with many new tests and many repaired
bugs. This release also introduces a few new key features which were brought
in primarily to repair bugs and some limitations found in some of the
components of the original architecture.
Salt 0.10.2 Release Notes
=========================
0.10.2 is out! This release comes with enhancements to the pillar interface,
cleaner ways to access the salt-call capabilities in the API, minion data
caching and the event system has been added to salt minions.
There have also been updates to the zeromq functions, many more tests
(thanks to sponsors, the code sprint and many contributors) and a swath
of bug fixes.
Salt 0.10.3 Release Notes
=========================
The latest taste of Salt has come, this release has many fixes and feature
additions. Modifications have been made to make ZeroMQ connections more
reliable, the begining of the ACL system is in place, a new command line
parsing system has been added, dynamic module distribution has become more
environment aware, the new `master_finger` option and many more!
Salt 0.10.4 Release Notes
=========================
Salt 0.10.4 is a monumental release for the Salt team, with two new module
systems, many additions to allow granular access to Salt, improved platform
support and much more.
This release is also exciting because we have been able to shorten the release
cycle back to under a month. We are working hard to keep up the aggressive pace
and look forward to having releases happen more frequently!
This release also includes a serious security fix and all users are very
strongly recommended to upgrade. As usual, upgrade the master first, and then
the minion to ensure that the process is smooth.
Salt 0.10.5 Release Notes
=========================
Salt 0.10.5 is ready, and comes with some great new features. A few more
interfaces have been modularized, like the outputter system. The job cache
system has been made more powerful and can now store and retrieve jobs archived
in external databases. The returner system has been extended to allow minions
to easily retrieve data from a returner interface.
As usual, this is an exciting release, with many noteworthy additions!
2012-12-06 09:01:21 +01:00
|
|
|
|
|
|
|
|
# Dependencies are documented at
|
|
|
|
|
# http://docs.saltstack.org/en/latest/topics/installation/index.html#dependencies
|
|
|
|
|
# Jinja2 is documented as an optional dependency, but it's small so we
|
|
|
|
|
# include it unconditionally.
|
|
|
|
|
#
|
|
|
|
|
# There's also an optional dependency on gcc, for Cython support, but
|
|
|
|
|
# we don't bother with that here.
|
|
|
|
|
#
|
. Fixed rc.d script by adding comment_interpreter
. Updated salt to version 0.15.0
From SaltStack website:
Salt 0.15.0 comes with many smaller features and a few larger ones.
The Salt Mine
First there was the peer system, allowing for commands to be executed from a
minion to other minions to gather data live. Then there was the external job
cache for storing and accessing long term data. Now the middle ground is being
filled in with the Salt Mine. The Salt Mine is a system used to execute
functions on a regular basis on minions and then store only the most recent
data from the functions on the master, then the data is looked up via targets.
The mine caches data that is public to all minions, so when a minion posts
data to the mine all other minions can see it.
IPV6 Support
0.13.0 saw the addition of initial IPV6 support but errors were encountered
and it needed to be stripped out. This time the code covers more cases and
must be explicitly enabled. But the support is much more extensive than before.
Copy Files From Minions to the Master
Minions have long been able to copy files down from the master file server,
but until now files could not be easily copied from the minion up to the
master.
A new function called cp.push can push files from the minions up to the master
server. The uploaded files are then cached on the master in the master
cachedir for each minon.
Better Template Debugging
Template errors have long been a burden when writing states and pillar. 0.15.0
will now send the compiled template data to the debug log, this makes tracking
down the intermittent stage templates much easier. So running state.sls or
state.highstate with -l debug will now print out the rendered templates in the
debug information.
State Event Firing
The state system is now more closely tied to the master's event bus. Now when
a state fails the failure will be fired on the master event bus so that the
reactor can respond to it.
Major Syndic Updates
The Syndic system has been basically re-written. Now it runs in a completely
asynchronous way and functions primarily as an event broker. This means that
the events fired on the syndic are now pushed up to the higher level master
instead of the old method used which waited for the client libraries to return.
This makes the syndic much more accurate and powerful, it also means that all
events fired on the syndic master make it up the pipe as well making a reactor
on the higher level master able to react to minions further downstream.
Peer System Updates
The Peer System has been updated to run using the client libraries instead of
firing directly over the publish bus. This makes the peer system much more
consistent and reliable.
Minion Key Revocation
In the past when a minion was decommissioned the key needed to be manually
deleted on the master, but now a function on the minion can be used to revoke
the calling minion's key:
salt-call saltutil.revoke_auth
Function Return Codes
Functions can now be assigned numeric return codes to determine if the
function executed successfully. While not all functions have been given return
codes, many have and it is an ongoing effort to fill out all functions that
might return a non-zero return code.
Functions in Overstate
The overstate system was originally created to just manage the execution of
states, but with the addition of return codes to functions, requisite logic
can now be used with respect to the overstate. This means that an overstate
stage can now run single functions instead of just state executions.
Pillar Error Reporting
Previously if errors surfaced in pillar, then the pillar would consist of only
and empty dict. Now all data that was successfully rendered stays in pillar
and the render error is also made available. If errors are found in the
pillar, states will refuse to run.
Using Cached State Data
Sometimes states are executed purely to maintain a specific state rather than
to update states with new configs. This is grounds for the new cached state
system. By adding cache=True to a state call the state will not be generated
fresh from the master but the last state data to be generated will be used.
If no previous state data is available then fresh data will be generated.
Monitoring States
The new monitoring states system has been started. This is very young but
allows for states to be used to configure monitoring routines. So far only one
monitoring state is available, the disk.status state. As more capabilities are
added to Salt UI the monitoring capabilities of Salt will continue to be
expanded.
2013-05-05 14:26:23 +02:00
|
|
|
.include "../../lang/python/application.mk"
|
2012-01-21 21:26:58 +01:00
|
|
|
.include "../../lang/python/distutils.mk"
|
|
|
|
|
.include "../../mk/bsd.pkg.mk"
|
