Merge remote branch 'nico/master'

This commit is contained in:
Steven Armstrong 2011-02-20 11:29:00 +01:00
commit 3619013f25
3 changed files with 46 additions and 22 deletions

1
.gitignore vendored
View file

@ -1 +1,2 @@
.*.swp
doc/man/*.[1-9]

View file

@ -3,6 +3,15 @@ BINDIR=$(PREFIX}/bin
WEBDIR=$$HOME/niconetz
WEBPAGE=software/cdist.mdwn
MANSRC=doc/man/cdist-config-layout.text doc/man/cdist-config.text \
doc/man/cdist-deploy-to.text doc/man/cdist-design.text \
doc/man/cdist-environment.text doc/man/cdist-explorers.text \
doc/man/cdist-language.text doc/man/cdist-manifests.text \
doc/man/cdist-quickstart.text doc/man/cdist-stages.text \
doc/man/cdist-terms.text doc/man/cdist.text \
doc/man/cdist-types.text
# FIXME: some distro nerd, can you make this more beautiful?
# I'm just a hacker, I don't really care...
install:
@ -23,3 +32,7 @@ web:
pub:
git push --mirror
man:
echo $(MANSRC)
a2x -f manpage --no-xmllint doc/man/cdist-stages.text

View file

@ -11,30 +11,38 @@ cdist-stages - How the configuration is built
DESCRIPTION
-----------
Starting the execution of deployment with cdist-deploy-to(1),
cdist passes through different stages:
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.
- First stage: Get information about target
Every existing explorer is run on the target and the results
are copied back into the local cache.
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.
See cdist-explorers(7) and see cdist-cache(7).
- Second stage: Initial manifest run
The initial manifest (see cdist-manifests(7) is run,
which is done by cdist-manifest-init(1).
Related manpages are cdist-explorers(7) and cdist-cache(7).
This run creates an internal database in cconfig
format (see cdist-config-layout(7), that contains all
objects configured 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.
STAGE 2: RUN THE INITIAL MANIFEST
---------------------------------
The initial manifest, which should be used for mappings
of hosts to types, is executed.
You can trigger the first stage part using
cdist-manifest-init(1).
This stage creates objects in a cconfig database that
contains as defined in the manifest for the specific host.
- Third stage: Execution of types [TODO]
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
@ -50,7 +58,8 @@ cdist passes through different stages:
objects try to create the same object, which indicates a
broken configuration.
- Fourth stage: Code generation [TODO]
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.
@ -62,7 +71,8 @@ cdist passes through different stages:
A description of what the generated code may/must/should
do can be found in cdist-types-gencode(7).
- Fifth stage: [TODO]
STAGE 5: CODE EXECUTION
-----------------------
The resulting code is transferred to the target host and executed,
the run of cdist-deploy-to(1) ends.