begin document cdist-stages

Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
Nico Schottelius 2011-02-07 22:46:47 +01:00
parent 3112534213
commit edc82f5423
2 changed files with 78 additions and 63 deletions

78
doc/man/cdist-stages.text Normal file
View file

@ -0,0 +1,78 @@
cdist-types(7)
===============
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-types - Functionality bundled
DESCRIPTION
-----------
First stage: [done]
- If cdist encounters type in manifest,
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>:
myhost/__file/cdist_bin/source
myhost/__file/cdist_bin/destination
...
- In this stage, no conflicts may occur, as
no type code has been called (i.e. only
manifests, which map config to hosts is
applied).
Second stage: [done]
- The "init" script of every used type
(i.e. the manifests created at least one object)
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
"webroot" type with --path / ...
# FIND CASE WHERE SENSEFUL => look through
current puppet config
- The newly created objects are merged back into
the existing tree. No conflicts may occur during
the merge, because this would implicit that the
type conflicts with other types.
The idea of this that a type may expand another
type with functionality, but may need to adjust
("overwrite") settings from the original type.
Third stage:
- Cdist calls the "gencode" binary of the types
for every created object. 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 at the end of this document.
- Cdist merges together the generated code
(taking care of DEPENDENCIES (which are not
yet defined (take care, double nested brackets)))
Fourth stage:
- The resulting shell script is transferred
to the target and executed.
SEE ALSO
--------
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).

View file

@ -66,69 +66,6 @@ type layout:
config # binary that is called to adjust cconfig tree config # binary that is called to adjust cconfig tree
change # binary that is called on the remote host? change # binary that is called on the remote host?
-------------------------------------------------------------------------------- --------------------------------------------------------------------------------
cdist view on types:
How types are integrated/run:
First stage: [done]
- If cdist encounters type in manifest,
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>:
myhost/__file/cdist_bin/source
myhost/__file/cdist_bin/destination
...
- In this stage, no conflicts may occur, as
no type code has been called (i.e. only
manifests, which map config to hosts is
applied).
Second stage: [done]
- The "init" script of every used type
(i.e. the manifests created at least one object)
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
"webroot" type with --path / ...
# FIND CASE WHERE SENSEFUL => look through
current puppet config
- The newly created objects are merged back into
the existing tree. No conflicts may occur during
the merge, because this would implicit that the
type conflicts with other types.
The idea of this that a type may expand another
type with functionality, but may need to adjust
("overwrite") settings from the original type.
Third stage:
- Cdist calls the "gencode" binary of the types
for every created object. 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 at the end of this document.
- Cdist merges together the generated code
(taking care of DEPENDENCIES (which are not
yet defined (take care, double nested brackets)))
Fourth stage:
- The resulting shell script is transferred
to the target and executed.
--------------------------------------------------------------------------------
Scope of code execution on the client Scope of code execution on the client
It should be assumed that the clients are pretty dumb It should be assumed that the clients are pretty dumb