valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-07 17:09:03 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

1) Fixed syntax error affecting yaml code block. 2) A couple grammmar fixes. 3) Added section on return data for states

Browse Source
This commit is contained in:
Erik Johnson 2012-01-29 19:48:45 -06:00
parent 56ac9dec70
commit e2eaef1f44
1 changed files with 18 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
doc/ref/states/writing.rst
View File

@ -14,7 +14,6 @@ passed to the SLS data structures will map directly to the states modules.
Mapping the information from the SLS data is simple, this example should
illustrate:
SLS file
.. code-block:: yaml
/etc/salt/master: # maps to "name"
@ -35,11 +34,11 @@ directly define the user interface.
Cross Calling Modules
=====================
As with Execution Modules State Modules can also make use of the ``__salt__``
As with Execution Modules, State Modules can also make use of the ``__salt__``
and ``__grains__`` data.
It is important to note, that the real work of state management should not be
done in the state module unless it is needed, a good example is the pkg state
It is important to note that the real work of state management should not be
done in the state module unless it is needed. A good example is the pkg state
module. This module does not do any package management work, it just calls the
pkg execution module. This makes the pkg state module completely generic, which
is why there is only one pkg state module and many backend pkg execution
@ -49,3 +48,18 @@ On the other hand some modules will require that the logic be placed in the
state module, a good example of this is the file module. But in the vast
majority of cases this is not the best approach, and writing specific
execution modules to do the backend work will be the optimal solution.
Return Data
===========
A State Module must return a dict containing the following keys/values:
- **name:** The same value passed to the state as "name".
- **changes:** A dict describing the changes made. Each thing changed should
be a key, with its value being another dict with keys called "old" and "new"
containing the old/new values. For example, the pkg state's **changes** dict
has one key for each package changed, with the "old" and "new" keys in its
sub-dict containing the old and new versions of the package.
- **result:** A boolean value. *True* if the action was successful, otherwise
*False*
- **comment:** A string containing a summary of the result.