cleanup and remove cdist-design.text

Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
Nico Schottelius 2011-02-26 11:27:53 +01:00
parent 0945b0fdb9
commit 0792e5aae3
4 changed files with 14 additions and 91 deletions

View file

@ -46,6 +46,10 @@ but is not. Or: The reason why I began to write cdist.
* It is very easy to
* extend cdist
* debug cdist-core and cdist-types
* Focus on reuse of existing functionality
* ssh
* sh
* find, rm, ...
## Requirements
@ -61,7 +65,13 @@ but is not. Or: The reason why I began to write cdist.
* SSH-Client (for pull architecture)
* SSH-Server (for push architecture)
## How to get cdist
## Installation
### Get cdist
Operation on the server is run as "cdist" user.
Operation on the client is run as "root" user.
git clone git://git.schottelius.org/cdist

View file

@ -47,8 +47,6 @@ x execute code on client (stage 5)
- ensure every file in bin/ has a correspondent manpage
- cdist manpage (main manpage)
- cleanup following man + their tree:
- cdist-language [CLEANUP AND REMOVE]
- cdist-design.text [CLEANUP AND REMOVE]
- cdist-push-pull [WRITE]
- cdist-quickstart [WRITE]
- how to write a minimal host manifest
@ -81,8 +79,7 @@ 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: exported variables:
__type, __explorer, __type_explorer, __object, __object_id
- DOC: exported variables: __type, __explorer, __type_explorer, __object, __object_id
- cleanup READMEs
- Check all references in manpages, ensure all manpages exist

View file

@ -33,3 +33,5 @@ Documentation:
- saves connection delay for new connections: -M
- hint: http://protempore.net/~calvins/howto/ssh-connection-sharing/
- Describe pull architecture and requirements
- cdist-trigger after first run from /var/lib/cdist/out/bin?
- Different environments (production, integration, development)

View file

@ -1,86 +0,0 @@
cdist-design(7)
===============
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-design - Design ideas for cdist
DESCRIPTION
-----------
When using cdist with the push principle, the execution tree looks likes this:
--------------------------------------------------------------------------------
% server
cdist-deploy-to(1) # main tool for deployment
cdist-config(1) # setup environment
cdist-build(1) # coordinates build process / dummy otherwise
cdist-preprocess(1) # fills up variables with content
cdist-explore(1) % client # explores client configuration
cdist-compile(1) # parses configuration,
# creates internal state in cconfig format,
# verifies configuration
cdist-link(1) # uses cconfig output, creates executable
cdist-remote-exec(1) # coordinates remote execution, dummy otherwise
cdist-transfer(1) # transfer executable to client
cdist-execute(1) % client # execute resulting executable
--------------------------------------------------------------------------------
Operation on the server is run as "cdist" user.
Operation on the client is run as "root" user.
When using cdist with the pull principle (configuration triggered by client):
--------------------------------------------------------------------------------
% client
cdist-trigger(1) <server-hostname> # connects to server
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
--------
cdist(7), website: http://www.nico.schottelius.org/cdist/[]
COPYING
-------
Copyright \(C) 2010-2011 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).