define stages
Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
Nico Schottelius
parent
edc82f5423
commit
e43e910012
1 changed files with 48 additions and 48 deletions
|
|
@ -1,75 +1,75 @@
|
||||||
cdist-types(7)
|
cdist-stages(7)
|
||||||
===============
|
===============
|
||||||
Nico Schottelius <nico-cdist--@--schottelius.org>
|
Nico Schottelius <nico-cdist--@--schottelius.org>
|
||||||
|
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
cdist-types - Functionality bundled
|
cdist-stages - How the configuration is built
|
||||||
|
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
First stage: [done]
|
Starting the execution of deployment with cdist-deploy-to(1),
|
||||||
- If cdist encounters type in manifest,
|
cdist passes through different stages:
|
||||||
a wrapper script is run, that creates a
|
|
||||||
new entry in the cconfig database and adds
|
|
||||||
attribute values. This defines a cconfig
|
|
||||||
tree, that may look as follows:
|
|
||||||
|
|
||||||
<hostname>/<type>/<id>/<parameters>:
|
- First stage: Get information about target
|
||||||
|
Every existing explorer (see cdist-explorers(7) is run on
|
||||||
|
the target and the results are copied back into the local
|
||||||
|
cache (see cdist-cache(7)). These values can be used by
|
||||||
|
manifests and types.
|
||||||
|
|
||||||
myhost/__file/cdist_bin/source
|
- Second stage: Initial manifest run
|
||||||
myhost/__file/cdist_bin/destination
|
The initial manifest (see cdist-manifests(7) is run,
|
||||||
...
|
which is done by cdist-manifest-init(1).
|
||||||
|
|
||||||
- In this stage, no conflicts may occur, as
|
This run creates an internal database in cconfig
|
||||||
no type code has been called (i.e. only
|
format (see cdist-config-layout(7), that contains all
|
||||||
manifests, which map config to hosts is
|
objects configured for the specific host.
|
||||||
applied).
|
|
||||||
|
|
||||||
Second stage: [done]
|
In this stage, no conflicts may occur, i.e. no
|
||||||
- The "init" script of every used type
|
object of the same type with the same id may
|
||||||
(i.e. the manifests created at least one object)
|
be created.
|
||||||
is called, which again is able to call other
|
|
||||||
types. All created objects may also be modified
|
|
||||||
by the type.
|
|
||||||
|
|
||||||
For instance a "httpd" type may call the
|
You can trigger the first stage part using
|
||||||
"webroot" type with --path / ...
|
cdist-manifest-init(1).
|
||||||
# FIND CASE WHERE SENSEFUL => look through
|
|
||||||
current puppet config
|
|
||||||
|
|
||||||
- The newly created objects are merged back into
|
- Third stage: Execution of types
|
||||||
the existing tree. No conflicts may occur during
|
Every object is checked whether its type has an init
|
||||||
the merge, because this would implicit that the
|
script (see cdist-types(7)). If the type of the object
|
||||||
type conflicts with other types.
|
has an init script, it is run. This init script may
|
||||||
|
generate additional objects.
|
||||||
|
|
||||||
The idea of this that a type may expand another
|
For instance the object __apache/www.test.ch is of
|
||||||
type with functionality, but may need to adjust
|
type __apache, which may contain an init script, which
|
||||||
("overwrite") settings from the original type.
|
creates new objects of type __file.
|
||||||
|
|
||||||
Third stage:
|
The newly created objects are merged back into
|
||||||
- Cdist calls the "gencode" binary of the types
|
the existing tree. No conflicts may occur during
|
||||||
for every created object. This binary should create
|
the merge. A conflict would mean that two different
|
||||||
code to be executed on the target on stdout.
|
objects try to create the same object, which indicates a
|
||||||
|
broken configuration.
|
||||||
|
|
||||||
If the gencode binary fails, it must print diagnostic
|
- Third stage: Code generation
|
||||||
messages on stderr and exit non-zero.
|
The "gencode" binary of the types for every existing object is
|
||||||
|
called to generate code that will be executed on the target host.
|
||||||
|
|
||||||
A description of what the generated code may/must/should
|
This binary should create code to be executed on the target on stdout.
|
||||||
do can be found at the end of this document.
|
|
||||||
|
|
||||||
- Cdist merges together the generated code
|
If the gencode binary fails, it must print diagnostic messages on stderr
|
||||||
(taking care of DEPENDENCIES (which are not
|
and exit non-zero.
|
||||||
yet defined (take care, double nested brackets)))
|
|
||||||
|
A description of what the generated code may/must/should
|
||||||
|
do can be found in cdist-types-gencode(7).
|
||||||
|
|
||||||
|
- Fourth stage:
|
||||||
|
The resulting code is transferred to the target host and executed,
|
||||||
|
the run of cdist-deploy-to(1) ends.
|
||||||
|
|
||||||
Fourth stage:
|
|
||||||
- The resulting shell script is transferred
|
|
||||||
to the target and executed.
|
|
||||||
|
|
||||||
SEE ALSO
|
SEE ALSO
|
||||||
--------
|
--------
|
||||||
|
cdist(7), cdist-deploy-to(1), cdist-config-layout(7), cdist-manifest-init(1)
|
||||||
|
|
||||||
|
|
||||||
COPYING
|
COPYING
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue