begin to cleanup doc/man/cdist-types.text
Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
		
					parent
					
						
							
								b8156ebede
							
						
					
				
			
			
				commit
				
					
						8513cca4d1
					
				
			
		
					 1 changed files with 38 additions and 76 deletions
				
			
		| 
						 | 
				
			
			@ -10,33 +10,40 @@ cdist-types - Functionality bundled
 | 
			
		|||
 | 
			
		||||
DESCRIPTION
 | 
			
		||||
-----------
 | 
			
		||||
A cdist type describes some kind of functionality.
 | 
			
		||||
Types can be run from manifests.
 | 
			
		||||
It is recommeneded to prefix all types with two
 | 
			
		||||
underscores, because types will be executed and
 | 
			
		||||
thus you prevent collisions with real binaries
 | 
			
		||||
(like "file").
 | 
			
		||||
A cdist type describes some kind of functionality, starting from
 | 
			
		||||
simple stuff like copying files until complex user auth/ldap/
 | 
			
		||||
kerberos infrastructure designs.
 | 
			
		||||
 | 
			
		||||
This document is a brainstorming document, on how to integrate types.
 | 
			
		||||
The name of every type is prefixed with two underscores (__),
 | 
			
		||||
because types will be executed and the two underscores prevent
 | 
			
		||||
collisions with real binaries (like "file").
 | 
			
		||||
 | 
			
		||||
Proposed/discussed structures:
 | 
			
		||||
It must be assumed that the clients are pretty dumb
 | 
			
		||||
and thus do not have high level tools like python
 | 
			
		||||
installed.
 | 
			
		||||
 | 
			
		||||
1) 2010-11-02
 | 
			
		||||
   $basedir/$type/
 | 
			
		||||
      properties/
 | 
			
		||||
         name/
 | 
			
		||||
            required # required | optional
 | 
			
		||||
         choices  # \n liste
 | 
			
		||||
If a type requires specific tools to be present
 | 
			
		||||
on the target, there must be another type that
 | 
			
		||||
provides this tool and the first type must create
 | 
			
		||||
an object of the specific type.
 | 
			
		||||
 | 
			
		||||
If the generated code fails on the client, it must
 | 
			
		||||
print diagnostistic messages on stderr and call
 | 
			
		||||
"exit 1", so the configuration is aborted.
 | 
			
		||||
 | 
			
		||||
   - are independent of hosts in general
 | 
			
		||||
   - may make use of other types to realise a new type
 | 
			
		||||
   - can overwrite stuff (HOW?)
 | 
			
		||||
      - 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 
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
      meta/
 | 
			
		||||
         default (shell script)
 | 
			
		||||
      types/
 | 
			
		||||
         pukman/
 | 
			
		||||
 | 
			
		||||
2) 2010-11-09
 | 
			
		||||
 | 
			
		||||
How to write my own type named "coffee":
 | 
			
		||||
HOW TO WRITE A NEW TYPE (TODO)
 | 
			
		||||
-----------------------
 | 
			
		||||
Assume you want to create the new type named "coffee":
 | 
			
		||||
 | 
			
		||||
Create the directory /etc/cdist/types/coffee/
 | 
			
		||||
Create the file /etc/cdist/types/coffee/README containing a description of the 
 | 
			
		||||
| 
						 | 
				
			
			@ -58,51 +65,6 @@ attributes.
 | 
			
		|||
shell code suitable for running on the client.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
--------------------------------------------------------------------------------
 | 
			
		||||
type layout:
 | 
			
		||||
 | 
			
		||||
   <name>/
 | 
			
		||||
      config   # binary that is called to adjust cconfig tree
 | 
			
		||||
      change   # binary that is called on the remote host?
 | 
			
		||||
--------------------------------------------------------------------------------
 | 
			
		||||
Scope of code execution on the client
 | 
			
		||||
 | 
			
		||||
   It should be assumed that the clients are pretty dumb
 | 
			
		||||
   and thus do not have high level tools like python
 | 
			
		||||
   installed.
 | 
			
		||||
 | 
			
		||||
   If a type requires specific tools to be present
 | 
			
		||||
   on the target, there must be another type that
 | 
			
		||||
   provides this tool and the first type must create
 | 
			
		||||
   an object of the specific type.
 | 
			
		||||
 | 
			
		||||
   If the generated code fails on the client, it must
 | 
			
		||||
   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