78 lines
		
	
	
	
		
			2.4 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			78 lines
		
	
	
	
		
			2.4 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
cdist-stages(7)
 | 
						|
===============
 | 
						|
Nico Schottelius <nico-cdist--@--schottelius.org>
 | 
						|
 | 
						|
 | 
						|
NAME
 | 
						|
----
 | 
						|
cdist-stages - How the configuration is built
 | 
						|
 | 
						|
 | 
						|
DESCRIPTION
 | 
						|
-----------
 | 
						|
Starting the execution of deployment with cdist-deploy-to(1),
 | 
						|
cdist passes through different stages:
 | 
						|
 | 
						|
- 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.
 | 
						|
 | 
						|
- Second stage: Initial manifest run
 | 
						|
   The initial manifest (see cdist-manifests(7) is run,
 | 
						|
   which is done by cdist-manifest-init(1).
 | 
						|
   
 | 
						|
   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.
 | 
						|
   
 | 
						|
   You can trigger the first stage part using
 | 
						|
   cdist-manifest-init(1).
 | 
						|
 | 
						|
- Third stage: 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
 | 
						|
   generate additional objects.
 | 
						|
 | 
						|
   For instance the object __apache/www.test.ch is of
 | 
						|
   type __apache, which may contain an init script, which
 | 
						|
   creates new objects of type __file.
 | 
						|
 | 
						|
   The newly created objects are merged back into
 | 
						|
   the existing tree. No conflicts may occur during
 | 
						|
   the merge. A conflict would mean that two different
 | 
						|
   objects try to create the same object, which indicates a
 | 
						|
   broken configuration.
 | 
						|
 | 
						|
- Fourth stage: Code generation [TODO]
 | 
						|
   The "gencode" binary of the types for every existing object is
 | 
						|
   called to generate code that will be executed on the target host.
 | 
						|
 | 
						|
   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 in cdist-types-gencode(7).
 | 
						|
 | 
						|
- Fifth stage: [TODO]
 | 
						|
   The resulting code is transferred to the target host and executed,
 | 
						|
   the run of cdist-deploy-to(1) ends.
 | 
						|
 | 
						|
 | 
						|
SEE ALSO
 | 
						|
--------
 | 
						|
cdist(7), cdist-deploy-to(1), cdist-config-layout(7), cdist-manifest-init(1)
 | 
						|
 | 
						|
 | 
						|
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).
 |