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

copyedit states/layers.rst

Browse Source
This commit is contained in:
Chris Rebert 2013-06-10 17:11:29 -07:00
parent b7a99c019a
commit 7e79440c8d
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
doc/ref/states/layers.rst
View File

@ -2,16 +2,16 @@
State System Layers
===================
The salt state system is comprised of multiple layers. While using Salt does
not require an understanding of the state layers a deeper understanding of
The Salt state system is comprised of multiple layers. While using Salt does
not require an understanding of the state layers, a deeper understanding of
how Salt compiles and manages states can be very beneficial.
Function Call
=============
The lowest layer of functionality in the state system is the direct state
function call. Sate executions are executions of single state functions at
the core, these individual functions are defined in state modules and can
function call. State executions are executions of single state functions at
the core. These individual functions are defined in state modules and can
be called directly via the ``state.single`` command.
.. code-block:: bash
@ -38,7 +38,7 @@ Low State
=========
The `Low State` layer is the list of low chunks "evaluated" in order. To see
what the low state look like for a highstate run:
what the low state looks like for a highstate, run:
.. code-block:: bash
@ -47,7 +47,7 @@ what the low state look like for a highstate run:
This will display the raw lowstate in the order which each low chunk will be
evaluated. The order of evaluation is not necessarily the order of execution,
since requisites are evaluated at runtime. Requisite execution and evaluation
is finite, this means that the order of execution can be ascertained with 100%
is finite; this means that the order of execution can be ascertained with 100%
certainty based on the order of the low state.
High Data
@ -57,8 +57,8 @@ High data is the data structure represented in YAML via SLS files. The High
data structure is created by merging the data components rendered inside sls
files (or other render systems). The High data can be easily viewed by
executing the ``state.show_highstate`` or ``state.show_sls`` functions. Since
this data is a somewhat complex data structure it may be easier to read using
the json, yaml or pprint outputters:
this data is a somewhat complex data structure, it may be easier to read using
the json, yaml, or pprint outputters:
.. code-block:: bash
@ -68,7 +68,7 @@ the json, yaml or pprint outputters:
SLS
====
Above "High Data" the logical layers are no longer technically required to be
Above "High Data", the logical layers are no longer technically required to be
executed, or to be executed in a hierarchy. This means that how the High data
is generated is optional and very flexible. The SLS layer allows for many
mechanisms to be used to render sls data from files or to use the fileserver
@ -80,11 +80,11 @@ The SLS layer can be called directly to execute individual sls formulas.
SLS Formulas have historically been called "SLS files". This is because a
single SLS was only constituted in a single file. Now the term
"SLS Formula" better expresses how a comparmentalized SLS can be expressed
in a much mroe dynamic way by combining pillar, other sources, and the
"SLS Formula" better expresses how a compartmentalized SLS can be expressed
in a much more dynamic way by combining pillar and other sources, and the
SLS can be dynamically generated.
To call a single SLS formula called "edit.vim" execute ``state.sls``:
To call a single SLS formula named ``edit.vim``, execute ``state.sls``:
.. code-block:: bash
@ -96,8 +96,8 @@ HighState
Calling SLS directly logically assigns what states should be executed from the
context of the calling minion. The Highstate layer is used to allow for full
contextual assignment of what is executed where to be tied to groups of, or
individual minions entirely from the master. This means that the environment of
a minion, and all associated execution data pertinent to said minion an be
individual, minions entirely from the master. This means that the environment of
a minion, and all associated execution data pertinent to said minion, can be
assigned from the master without needing to execute or configure anything on
the target minion. This also means that the minion can independently retrieve
information about its complete configuration from the master.