cleanup cdist manpage, add todos at various positions

Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
Nico Schottelius 2010-11-01 16:19:54 +01:00
parent 686f50d106
commit 88d9cf13de
6 changed files with 96 additions and 107 deletions

17
TODO
View file

@ -1,5 +1,8 @@
- doc: - doc:
- cdist manpage (main manpage) - cdist manpage (main manpage)
- cleanup following man + their tree:
- cdist.text
- cdist-design.text
- add terminology - add terminology
- define entry point - define entry point
- define modules / mix with library? - define modules / mix with library?
@ -43,6 +46,20 @@
- disconnected clients with "cache" - disconnected clients with "cache"
- release first public version, which includes at least: - release first public version, which includes at least:
- manpages - manpages
- only do necessary work
- install packages only if not existent
- copy file only if different
Before initial release, document:
- how to add package backends
- how to write a minimal host manifest
- create library with all functions (and their parameters)
- cdist_package
- cdist_file
- cdist_dir
-------------------------------------------------------------------------------- --------------------------------------------------------------------------------
Later: Later:

View file

@ -0,0 +1,9 @@
On the server:
conf/hosts/init $hostname
=> will be called by $whatever
=> may source other files
=> $__hosts_dir can be used to source other scripts
Cached client:
Has generated file, which will be (re-)applied

View file

@ -36,6 +36,41 @@ When using cdist with the pull principle (configuration triggered by client):
cdist-deploy-to(1) <client-hostname> % server: see above cdist-deploy-to(1) <client-hostname> % server: see above
-------------------------------------------------------------------------------- --------------------------------------------------------------------------------
MERGE INTO ABOVE.....
## How cdist works
### Exploring your system
cdist analyses the system to apply the configuration on and
selects the right backends. You can use ***cdist-explore*** to
the results of the explore functions.
### Applying the configuration
cdist looks for the configuration to apply on the local host
and applies it using ***cdist-apply***.
### Managing many hosts
Whereas ***cdist-apply*** manages one host, ***cdist-deploy***
applies the configuration on enabled hosts.
- version control via git
- file distribution via ssh
- authentication via ssh
- dumb clients, similar to manifest compile in puppet
- clients just execute commands
- dependencies via make?
- how to ensure sigletons / conflicting definitions?
file { "/a":
ensure => present,
file { "/a":
ensure => absent,
=>=>>>>>>>>>>>>>>>> via cconfig
SEE ALSO SEE ALSO
-------- --------
cdist(7), website: http://www.nico.schottelius.org/cdist/[] cdist(7), website: http://www.nico.schottelius.org/cdist/[]

View file

@ -29,6 +29,33 @@ The three stages are used to seperate configurations:
- the library is shipped with cdist, but can be extendet locally - 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
- library == functions?
- matching on explored items, not only on host name?
- match function in host? [optional]
- explorer ran before!
- document exported variables!
use __ prefix instead of __cdist (shorter writing, __ is defined as sytem anyway)
- library vs. modules?
Requirements:
It MUST be incredible easy/dumb to add new types.
=> growable default types
SEE ALSO SEE ALSO
-------- --------

View file

@ -0,0 +1,5 @@
## How to use cdist?
0. Create a host specification (/etc/cdist/hosts/**hostname**)
0. Add functionalilty to add
0. Run ***cdist-apply***

View file

@ -20,120 +20,16 @@ internal configuration representation (cconfig), which again
is used to generate an executable, which is run on the client is used to generate an executable, which is run on the client
(see cdist-language(7), cdist-design(7)). (see cdist-language(7), cdist-design(7)).
To get your fingers dirty with cdist very quick, have
a look at cdist-quickstart(7).
SEE ALSO SEE ALSO
-------- --------
cdist-deploy-to(1), website: http://www.nico.schottelius.org/cdist/[] Website: http://www.nico.schottelius.org/cdist/[]
COPYING COPYING
------- -------
Copyright \(C) 2010 Nico Schottelius. Free use of this software is Copyright \(C) 2010 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3). granted under the terms of the GNU General Public License version 3 (GPLv3).
--------------------------------------------------------------------------------
## How cdist works
### Exploring your system
cdist analyses the system to apply the configuration on and
selects the right backends. You can use ***cdist-explore*** to
the results of the explore functions.
### Applying the configuration
cdist looks for the configuration to apply on the local host
and applies it using ***cdist-apply***.
### Managing many hosts
Whereas ***cdist-apply*** manages one host, ***cdist-deploy***
applies the configuration on enabled hosts.
## How to use cdist?
0. Create a host specification (/etc/cdist/hosts/**hostname**)
0. Add functionalilty to add
0. Run ***cdist-apply***
--------------------------------------------------------------------------------
Simple stuff done by Unix[notm]
- 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
- library == functions?
- version control via git
- file distribution via ssh
- authentication via ssh
- dumb clients, similar to manifest compile in puppet
- clients just execute commands
- dependencies via make?
- how to ensure sigletons / conflicting definitions?
file { "/a":
ensure => present,
file { "/a":
ensure => absent,
- matching on explored items, not only on host name?
- match function in host? [optional]
- file source:
- relative to specification
- or absolute
--------------------------------------------------------------------------------
Implementation
"cdist-server"
-> called by cron?
-> no need to reimplement scheduling
"cdist-explore" (facter replacement)
-> running on the client
--------------------------------------------------------------------------------
Requirements:
It MUST be incredible easy/dumb to add new types.
=> growable default types
--------------------------------------------------------------------------------
## TO DOC
Before initial release, document:
- how to add package backends
- how to write a minimal host manifest
- create library with all functions (and their parameters)
- cdist_package
- cdist_file
- cdist_dir
- only do necessary work
- install packages only if not existent
- copy file only if different
- how to write a module
- module function autoloading via *.sh
- module "manifest"?
- create functions in *.sh
- name functions "modulename_function"
module hellow
function kitty
=> hellow_kitty
- you are advised (not forced) to put files
to a subdirectory named "files"