begin document cdist-stages
Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
Nico Schottelius
parent
3112534213
commit
edc82f5423
2 changed files with 78 additions and 63 deletions
78
doc/man/cdist-stages.text
Normal file
78
doc/man/cdist-stages.text
Normal 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).
|
||||
|
|
@ -66,69 +66,6 @@ type layout:
|
|||
config # binary that is called to adjust cconfig tree
|
||||
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
|
||||
|
||||
It should be assumed that the clients are pretty dumb
|
||||
|
|
|
|||
Loading…
Reference in a new issue