From edc82f5423f7e8dfc739a0b66a4f48b1c112187b Mon Sep 17 00:00:00 2001 From: Nico Schottelius Date: Mon, 7 Feb 2011 22:46:47 +0100 Subject: [PATCH] begin document cdist-stages Signed-off-by: Nico Schottelius --- doc/man/cdist-stages.text | 78 +++++++++++++++++++++++++++++++++++++++ doc/man/cdist-types.text | 63 ------------------------------- 2 files changed, 78 insertions(+), 63 deletions(-) create mode 100644 doc/man/cdist-stages.text diff --git a/doc/man/cdist-stages.text b/doc/man/cdist-stages.text new file mode 100644 index 00000000..0540682f --- /dev/null +++ b/doc/man/cdist-stages.text @@ -0,0 +1,78 @@ +cdist-types(7) +=============== +Nico Schottelius + + +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: + + ///: + + 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). diff --git a/doc/man/cdist-types.text b/doc/man/cdist-types.text index 828fa665..89b0fc6f 100644 --- a/doc/man/cdist-types.text +++ b/doc/man/cdist-types.text @@ -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: - - ///: - - 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