CVS commit: pkgsrc/sysutils/salt

["Emile iMil Heitor" <imil%netbsd.org@localhost>]

Module Name:    pkgsrc
Committed By:   imil
Date:           Sun May  5 12:26:23 UTC 2013

Modified Files:
        pkgsrc/sysutils/salt: Makefile PLIST distinfo
        pkgsrc/sysutils/salt/files: salt_master.sh salt_minion.sh

Log Message:
. 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.


To generate a diff of this commit:
cvs rdiff -u -r1.11 -r1.12 pkgsrc/sysutils/salt/Makefile
cvs rdiff -u -r1.4 -r1.5 pkgsrc/sysutils/salt/PLIST
cvs rdiff -u -r1.3 -r1.4 pkgsrc/sysutils/salt/distinfo
cvs rdiff -u -r1.1 -r1.2 pkgsrc/sysutils/salt/files/salt_master.sh \
    pkgsrc/sysutils/salt/files/salt_minion.sh

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.