forked from ungleich-public/cdist
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
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
A cdist type describes some kind of functionality.
|
A cdist type describes some kind of functionality, starting from
|
||||||
Types can be run from manifests.
|
simple stuff like copying files until complex user auth/ldap/
|
||||||
It is recommeneded to prefix all types with two
|
kerberos infrastructure designs.
|
||||||
underscores, because types will be executed and
|
|
||||||
thus you prevent collisions with real binaries
|
|
||||||
(like "file").
|
|
||||||
|
|
||||||
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
|
If a type requires specific tools to be present
|
||||||
$basedir/$type/
|
on the target, there must be another type that
|
||||||
properties/
|
provides this tool and the first type must create
|
||||||
name/
|
an object of the specific type.
|
||||||
required # required | optional
|
|
||||||
choices # \n liste
|
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/
|
HOW TO WRITE A NEW TYPE (TODO)
|
||||||
default (shell script)
|
-----------------------
|
||||||
types/
|
Assume you want to create the new type named "coffee":
|
||||||
pukman/
|
|
||||||
|
|
||||||
2) 2010-11-09
|
|
||||||
|
|
||||||
How to write my own type named "coffee":
|
|
||||||
|
|
||||||
Create the directory /etc/cdist/types/coffee/
|
Create the directory /etc/cdist/types/coffee/
|
||||||
Create the file /etc/cdist/types/coffee/README containing a description of the
|
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.
|
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
|
SEE ALSO
|
||||||
--------
|
--------
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue