forked from ungleich-public/cdist
90 lines
2.7 KiB
Plaintext
90 lines
2.7 KiB
Plaintext
cdist-stages(7)
|
|
===============
|
|
Nico Schottelius <nico-cdist--@--schottelius.org>
|
|
|
|
|
|
NAME
|
|
----
|
|
cdist-stages - How the configuration is built
|
|
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
Starting the execution of deployment with cdist-deploy-to(1),
|
|
cdist passes through different stages, each can be triggered
|
|
and debugged on its own. Reading the source of the
|
|
cdist-deploy-to script shous the binaries being responsible
|
|
for each stage.
|
|
|
|
STAGE 1: TARGET INFORMATION RETRIEVAL
|
|
--------------------------------------
|
|
In this stage information is collected about target using
|
|
so called explorers.
|
|
Every existing explorer is run on the target and the output
|
|
of all explorers are copied back into the local cache.
|
|
The results can be used by manifests and types.
|
|
|
|
Related manpages are cdist-explorers(7) and cdist-cache(7).
|
|
|
|
|
|
STAGE 2: RUN THE INITIAL MANIFEST
|
|
---------------------------------
|
|
The initial manifest, which should be used for mappings
|
|
of hosts to types, is executed.
|
|
|
|
This stage creates objects in a cconfig database that
|
|
contains as defined in the manifest for the specific host.
|
|
|
|
In this stage, no conflicts may occur, i.e. no object of
|
|
the same type with the same id may be created.
|
|
|
|
Related manpages are cdist-manifest-init(1), cdist-manifests(7) and
|
|
cdist-config-layout(7).
|
|
|
|
STAGE 3: EXECUTION OF TYPES
|
|
---------------------------
|
|
Every object is checked whether its type has an init
|
|
script (see cdist-types(7)). If the type of the object
|
|
has an init script, it is run. This init script may
|
|
generate additional objects.
|
|
|
|
For instance the object __apache/www.test.ch is of
|
|
type __apache, which may contain an init script, which
|
|
creates new objects of type __file.
|
|
|
|
The newly created objects are merged back into
|
|
the existing tree. No conflicts may occur during
|
|
the merge. A conflict would mean that two different
|
|
objects try to create the same object, which indicates a
|
|
broken configuration.
|
|
|
|
STAGE 4: CODE GENERATION
|
|
------------------------
|
|
The "gencode" binary of the types for every existing object is
|
|
called to generate code that will be executed on the target host.
|
|
|
|
This binary should create code to be executed on the target on stdout.
|
|
|
|
If the gencode binary fails, it must print diagnostic messages on stderr
|
|
and exit non-zero.
|
|
|
|
A description of what the generated code may/must/should
|
|
do can be found in cdist-types-gencode(7).
|
|
|
|
STAGE 5: CODE EXECUTION
|
|
-----------------------
|
|
|
|
The resulting code is transferred to the target host and executed,
|
|
the run of cdist-deploy-to(1) ends.
|
|
|
|
|
|
SEE ALSO
|
|
--------
|
|
cdist(7), cdist-deploy-to(1), cdist-config-layout(7), cdist-manifest-init(1)
|
|
|
|
|
|
COPYING
|
|
-------
|
|
Copyright \(C) 2010-2011 Nico Schottelius. Free use of this software is
|
|
granted under the terms of the GNU General Public License version 3 (GPLv3).
|