cdist-language cleanup

Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
Nico Schottelius 2011-02-26 11:19:43 +01:00
parent 13dc45e1de
commit 2b20d9914f
4 changed files with 31 additions and 44 deletions

View file

@ -57,6 +57,8 @@ x execute code on client (stage 5)
- install packages only if not existent
- copy file only if different
- cdist [IMPORTANT]
- explain the general approach
- give right pointers
- cdist-explorers
- add terminology
- define steps within configuration apply
@ -79,8 +81,9 @@ x execute code on client (stage 5)
- cdist-type integration!
- DOC document "cd $__object_dir, before running manifest" in doc/man/cdist-types.text
- DOC document that $type/manifest is executed for every object/instance
- DOC: types can always access __cdist_out_objects, __cdist_out_explorers, __cdist_out_execs
--> create cdist-variables document?
- DOC: exported variables:
__type, __explorer, __type_explorer, __object, __object_id
- cleanup READMEs
- Check all references in manpages, ensure all manpages exist

View file

@ -3,6 +3,9 @@ Core:
- probably name them only_once and use that as the internal id!
- remove remote_base_dir at beginning - otherwise fragments from
previous runs may still be existing!
-> probably also local_base_dir!
- cdist-deploy-to: Configure more than one host
- plus parallel mode like in ccollect
Type handler:
- add dependency parameters to core available for every type

View file

@ -16,31 +16,6 @@ A cdist configuration consists of the following parts:
- library (cdist-language-library(7))
- modules (cdist-language-modules(7))
In short the configuration is built as follows:
- conf/hosts/init is executed, the resulting output is used for module loading
- the appropriate modules are loaded and executed, which
- use library functions.
The three stages are used to seperate configurations:
- hosts contain mappings to created modules
- modules create (probably site specific) configurations using library collections
- the library is shipped with cdist, but can be extendet locally
- DSL: Shell!
- gives if, else and EVEN elsif for free!
- and case
- and and and
- and there's no os (solaris doesn't count) without a usable /bin/sh
- cdist defines what you can use
- you _can_ use os specific stuff
- but it's ugly and you shoot into your own foot
- "manifests" (use the same name here?) will be run/sourced
- inheritance possible via sourcing
- cdist-lib always preloaded
- document exported variables!
use __ prefix instead of __cdist (shorter writing, __ is defined as sytem anyway)

View file

@ -8,35 +8,41 @@ NAME
cdist - Configuration management system
NEW DESCRIPTION
-----------
- is cm
- quickstart - cdist-quickstart
- configured in shell dsl - pointers to posix and problems (sh != bash), os specific
- how to apply - cdist-deploy-to
- how to write - cdist-manifest, cdist-type
-
DESCRIPTION
-----------
Cdist allows you to centrally define a configurations for
UNIX systems and apply them. Cdist generally uses the push
approach (a server pushes out the configuration to the clients),
but can also be used the pull way (see cdist-push-pull(7)).
Cdist is a very simple, elegant, cleanly designed configuration management
system. Cdist allows you to centrally define configurations for UNIX systems
Cdist generally uses the push approach (a server pushes out the
configuration to the clients), but can also be used the pull way.
Cdist-deploy-to(1) is the main command to be used to deploy
configurations to a host.
Cdist-deploy-to is the main command to be used to configure a host.
The mapping of configurations to hosts is defined
in so called manifests, which are written in shell
script language (see cdist-manifest(7)).
The mapping of configurations to hosts is defined in so called manifests,
which are written in shell script language.
Logical units of files and directives are called "types" in cdist jargon
(see cdist-types(7)). Cdist ships with some types, which you can change
or create new ones or even submit your types for inclusion into mainstream
(see cdist-type-inclusion(7)).
Logical units of functionality are called "types" in cdist jargon. Cdist ships
with some types, which you can change or create new ones or even submit your
types for inclusion into cdist.
The fastest way to get a host configured using cdist is probably
cdist-quickstart(7).
The fastest way to get a host configured using cdist is probably using
cdist-quickstart.
SEE ALSO
--------
Website: http://www.nico.schottelius.org/cdist/[], cdist-push-pull(7),
cdist-deploy-to(1), cdist-manifest(7), cdist-types(7), cdist-type-inclusion(7),
cdist-quickstart(7)
cdist-quickstart(1)
COPYING
-------