merge back and forth ideas for further manpages
Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
		
					parent
					
						
							
								a3436bf775
							
						
					
				
			
			
				commit
				
					
						4ee71d5571
					
				
			
		
					 3 changed files with 45 additions and 4 deletions
				
			
		
							
								
								
									
										13
									
								
								TODO-1.0
									
										
									
									
									
								
							
							
						
						
									
										13
									
								
								TODO-1.0
									
										
									
									
									
								
							| 
						 | 
				
			
			@ -6,15 +6,20 @@ x Create configuration tree from manifest
 | 
			
		|||
   x write binaries, which create the tree when called from manifest (cdist_tree_wrapper)
 | 
			
		||||
x Define configuration paths (doc/internal/config-layout)
 | 
			
		||||
x Redo explorers (see manpage)
 | 
			
		||||
/ Write at least one type
 | 
			
		||||
 | 
			
		||||
- Parse configuration tree/objects recursively
 | 
			
		||||
   - can/may types modify tree?
 | 
			
		||||
      - may open door for getting information from manifest / other stuff
 | 
			
		||||
x Parse configuration tree/objects recursively
 | 
			
		||||
   x can/may types modify tree?
 | 
			
		||||
      -> yes, of everything a type created itself!
 | 
			
		||||
      x may open door for getting information from manifest / other stuff
 | 
			
		||||
 | 
			
		||||
- Cleanly define paths for object creation, especially recursive calls
 | 
			
		||||
 | 
			
		||||
- generate code to be executed on client
 | 
			
		||||
   - check return codes
 | 
			
		||||
   - abort on first error?
 | 
			
		||||
 | 
			
		||||
/ Write at least one type (completly!)
 | 
			
		||||
 | 
			
		||||
- doc 1.0:
 | 
			
		||||
   - cdist manpage (main manpage)
 | 
			
		||||
      - cleanup following man + their tree:
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -15,6 +15,21 @@ should be configured on a host.
 | 
			
		|||
 | 
			
		||||
ENTRYPOINT: $prefix/manifests/init
 | 
			
		||||
 | 
			
		||||
unsorted: cache / objects
 | 
			
		||||
   
 | 
			
		||||
   - 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
 | 
			
		||||
      ...
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
ENVIRONMENT
 | 
			
		||||
-----------
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -81,6 +81,27 @@ Scope of code execution on the client
 | 
			
		|||
   print diagnostistic messages on stderr and call
 | 
			
		||||
   "exit 1", so the configuration is aborted.
 | 
			
		||||
 | 
			
		||||
--------------------------------------------------------------------------------
 | 
			
		||||
   - have required and optional arguments
 | 
			
		||||
   - are independent of hosts
 | 
			
		||||
   - may make use of other types to realise a new type
 | 
			
		||||
      - how to overwrite stuff?
 | 
			
		||||
      - overwrite in own tree?
 | 
			
		||||
         - needs knowledge of inherited provider
 | 
			
		||||
            - similar to current situation in puppet,
 | 
			
		||||
              but more like reusable defines
 | 
			
		||||
   - or may implement some functionality on their own 
 | 
			
		||||
 | 
			
		||||
--------------------------------------------------------------------------------
 | 
			
		||||
Differences manifests vs. types
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
                     manifests               types
 | 
			
		||||
 | 
			
		||||
main purpose         map config to host      provide functionality
 | 
			
		||||
can change config    no (prevent conflicts)  yes (allow inheritance)
 | 
			
		||||
specificness         site specific           (globally) reusable
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
SEE ALSO
 | 
			
		||||
--------
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue