re-integrate log directory

Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>

doc/dev/logs/2010-09-25

@@ -0,0 +1,12 @@
+[12:15] kr:cdist% CDIST_DEBUG=1 cdist-config
+Debug: Loading /home/users/nico/p/cdist/conf/lib/cdist_dir.sh ...
+Debug: Loading /home/users/nico/p/cdist/conf/lib/cdist_explore_hostname.sh ...
+Debug: Loading /home/users/nico/p/cdist/conf/lib/cdist_explore_os.sh ...
+Debug: Loading /home/users/nico/p/cdist/conf/lib/cdist_explore_pkg_system.sh ...
+Debug: Loading /home/users/nico/p/cdist/conf/lib/cdist_file.sh ...
+Debug: Loading /home/users/nico/p/cdist/conf/lib/cdist_package.sh ...
+Debug: Loading /home/users/nico/p/cdist/conf/lib/cdist_package_backend_pacman_install.sh ...
+Debug: Loading /home/users/nico/p/cdist/conf/lib/cdist_package_select_backend.sh ...
+[12:15] kr:cdist% cdist-config              
+[12:15] kr:cdist% 
+

doc/dev/logs/2010-11-02.steven

@@ -0,0 +1,42 @@
+- Remote exec: always into file for debug purposes?
+- Argumente via evn(TYPNAME_PROPERTYNAME)?
+- Kleber zwischen package/provider/pacman/install und type/package/ muss in type oder sein!
+- $somebody defines default / mapping from $type to $provider
+   - may depend on $explore_variables
+
+- Alternativ dir structure?
+   $basedir/$type/
+      properties/
+         name/
+            required # required | optional
+         choices  # \n liste
+            
+
+      meta/
+         default (shell script)
+      providers/
+         pukman/
+
+- allow user to add or overwrite types, providers, etc.
+
+- property vs. option vs. parameter vs. attribute vs. mittagessen
+
+! cleanly define interface between type/provider and cdist core
+   - easy documentation generatior
+   - cool error messages
+   - up-to-date documentation
+   - validation of user input possible before type called (compile stage)
+
+- find $type => list of ${parameters/term to be defined/see above}
+
+- __package apache [--name nginx]
+   - type package defines mapping of unique id to ${parameters/term to be defined/see above}
+   - if --name given, creates config entry below apache
+
+- type2cconfig: define!
+- steven: git!!!!!!!!!! [TODAY!!!!!!!!!]
+- client status als cconfig => diff possibility
+   - vs. provider checks && cares abuot what todo
+
+- register creation in cconfig tree to find out how created the first entry!!!
+   - to warn user "created x already at y, trying to recreate at z"

doc/dev/logs/2010-11-09

@@ -0,0 +1,180 @@
+Rethinking ideas of last talk.
+
+What if types are formal / have formal arguments?
+What if cdist can do all the parsing stuff and the real
+functionality comes out of the library (similar to cfengine)?
+
+What if the library is integral part of cdist?
+
+
+conf/lib/$name/
+   attributes/
+      a
+      b
+      c
+
+
+--------------------------------------------------------------------------------
+I'm not sure whether this design is in fact helpful.
+But it's clearly necessary to have a directory per type, so a type can
+have helpers.
+
+
+conf/lib/$name/
+   init?
+
+
+Prepare some very minimal (non functional) framework for library integration?
+   Like parsing for command line arguments?
+
+--------------------------------------------------------------------------------
+Real configurations versus types:
+
+Types are reusable code: For instance etc_resolv.
+
+Configurations are types used and configured.
+
+
+--------------------------------------------------------------------------------
+
+Style
+
+   __type <id> --option1 <arg1> 
+
+   <id> = everything your filesystem permits, but may not start with a period (".").
+   If <id> == ., it setups the standard attributes.
+
+seems to be quite good usable. cdist can easily -----parse--- this.
+
+Nope. We don't parse. We let the shell execute.
+
+So whatever is __type will get executed.
+
+__type must probably be part of some cdist specific path.
+
+Which again could be
+
+   conf/lib/$name
+
+Which could result in the directory
+
+   conf/lib/.$name for helpers
+
+That style could include a mandority --help, --args arguments
+and would thus be independent of the language used (can, but does
+not must be shell).
+
+How to solve standard configurations that way?
+
+   EASY AS WELL!
+
+   __type <either option or magic> --option1 <arg1>
+   
+   for instance
+
+   __type . --option1 <arg1>
+
+
+--------------------------------------------------------------------------------
+Type paths
+   At least (at maximum)? 2:
+      user + system
+
+   Easy to do.
+
+--------------------------------------------------------------------------------
+Types: Name types types or name types modules?
+
+--------------------------------------------------------------------------------
+
+Where to place/start the configuration?
+
+   wherever it is: name it configuration!
+
+
+--------------------------------------------------------------------------------
+cdist installation / paths:
+
+   /etc/cdist/                   # CDISTBASEDIR
+      config/                    # CDISTCONFIGDIR
+      types/                     # CDISTUSERTYPEDIR 
+
+   $prefix/lib/cdist/types/      # CDISTSYSTYPEDIR
+
+
+cdist environment:
+   $__loaded_from                # path where $type has been loaded from
+   PATH=$CDISTUSERTYPEDIR:$CDISTSYSTYPEDIR:$PATH
+
+--------------------------------------------------------------------------------
+Recommendation (not a must):
+   Put helpers for types into the typedir/.$typename
+
+   All types should be prefixed by "__" to prevent clashes with the system
+   binaries.
+--------------------------------------------------------------------------------
+Type commands (__bla) could get generated by cdist and cdist could use that
+to generate the actual cconfig part.
+
+This leads up to the next section
+
+--------------------------------------------------------------------------------
+How to write my own type named "coffee":
+
+   Create the directory /etc/cdist/types/coffee/
+   Create the file /etc/cdist/types/coffee/README containing a description of the type.
+   If your type supports attributes, create the directory /etc/cdist/types/coffee/attributes.
+   For each attribute, create the file
+      /etc/cdist/types/coffee/attributes/$attribute_name which contains
+
+      a short description on the first line
+      then a blank line
+      then a long description (probably over several lines)
+
+   If you think your type may be useful for others, submit it for inclusion
+   into cdist at cdist -- at -- l.schottelius.org.
+
+   Create /etc/cdist/types/coffee/init which reads $configinput
+   (either via cconfig or via environment) and outputs a block of
+   shell code suitable for running on the client.
+
+
+--------------------------------------------------------------------------------
+
+cdist exec steps:
+
+   - check for valid types, abort if user (re-)defined system types
+   - generate __type binaries (aliases?), which contains cdist logic
+     to analyse types and check for correct arguments
+   - execute /etc/cdist/config/init (MAIN CONFIG) which in turn
+     calls __type binaries
+   - __type binaries (which are all the same, multicall!) generate
+     cconfig
+   - Run real type/init binaries with respective cconfig dir as path,
+     which must generate shellcode to be executed.
+   - Create the temporary shellscript containing all the code and execute
+     it on the client.
+
+--------------------------------------------------------------------------------
+Support metaargs like --depends?
+   If so, they need to be forbidden for types.
+--------------------------------------------------------------------------------
+Shell code generator:
+
+   - use subshells for each shellcodeblock
+   - create one main function (to ensure transfer is complete)
+
+Example:
+
+cdist_apply_$hostname()
+{
+
+   # repeat this block for every type/id defined
+   echo "Executing block from $type_$id ..."
+   (
+      code
+   )
+
+}
+
+cdist_apply_$hostname

doc/dev/logs/2010-11-21

@@ -0,0 +1,4 @@
+Ideas:
+   - rollback auf versionen
+      - backup
+

doc/dev/logs/2010-11-29

@@ -0,0 +1,4 @@
+- $type is handled by cdist and generates cconfig
+- $type itself gets called by cdist after cconfig generation
+   - $path as argument
+   - or chroot

doc/dev/logs/2010-12-01

@@ -0,0 +1,32 @@
+what does a type contain?
+
+   - possible explorer functions to find out about the system state
+   - scripts being run on the server, which inputs cconfig and generates code to
+     apply changes on the client
+     -> logs errors through stderr
+     -> 
+
+   - cdist takes all the type scripts, for each defined type
+      - when to run cdist-explorer tools from types?
+         - get general impression first and then consider tools?
+
+   - what about the overwrites / order / inherits problem?
+      - is a "how to reuse x"-problem
+      - NO OVERWRITE POSSIBLE!!!!!!!
+         - once defined, no redefine
+         - record creator to issue warning on collision detection!
+
+
+   - "i want to do the same as x, but change a single bit"
+      - i call the other type under my own name and overwrite stuff afterwards
+
+      - apache, tomcat, etc.
+         - 
+      TYPECHANGES are good!
+ 
+   - what is cm?
+      - copying files around
+      - changing files
+      - removing files
+      - put together in a context
+

doc/dev/logs/2011-01-17

@@ -0,0 +1,3 @@
+Steven:
+   Type == Provider == Module?
+   No need for providers like in Puppet (=> Providers can reuse other providers)

doc/dev/logs/2011-01-18.type-creation

@@ -0,0 +1,11 @@
+# How to create a new type - Try #1
+
+# Define possible parameters
+[21:10] kr:cdist% cd lib/types 
+[21:10] kr:types% mkdir file
+[21:10] kr:file% mkdir mandority_parameters
+[21:10] kr:file% touch mandority_parameters/name
+[21:11] kr:file% touch mandority_parameters/type
+[21:11] kr:file% mkdir optional_parameters      
+[21:11] kr:file% touch optional_parameters/mode
+

doc/dev/logs/2011-01-24

@@ -0,0 +1,92 @@
+Steven / Nico
+
+Type:
+   - xml/
+   
+   - parameters/
+   - optional_parameters
+      me: too long
+
+User interested it type:
+
+   - which arguments are available
+   - ls /path/to/type (steven)
+
+Steven / proposal:
+
+   - manifest/gencode: .meta
+   - attribute directly in dir
+
+"cdist-help" <type bla>
+
+   - if no direct path
+
+
+--------------------------------------------------------------------------------
+
+Doc proposal (Nico):
+
+   man cdist-type-<name>
+
+Directory structure:
+   "easy to ls -lR and understand what it does"
+
+   ls -lR $(cdist-type-path "typename")/meta/
+
+   ls -lR $(cdist-path type "typename")/meta/
+   
+--------------------------------------------------------------------------------
+
+What consumes most type?
+
+   - Writing types, because they are functionality
+   - Define attributes
+      - required/optional
+
+Type documentation
+
+   $type/.meta/required_parameters/path contains
+      "Path in which file is created"
+--------------------------------------------------------------------------------
+
+
+Doc of every type:
+
+   - required/optional parameters
+   - description
+
+--------------------------------------------------------------------------------
+
+! Validation of type input:
+
+   Not only required/optional parameters:
+
+   - handling of either content/source arguments
+
+   - validate script in type?
+   - seperate validation from manifest may be senseful
+--------------------------------------------------------------------------------
+
+Explorer per type?
+
+   - helpful or evil?
+   - helps to summarise/get information near ressource that needs it
+   - emphasises type specific explorers
+      -> explorer should be reusable by everybody!
+--------------------------------------------------------------------------------
+Explorer delivers facts
+
+   - central repo
+   - not being able to override 
+
+   - may be helpful to override facts for debugging (i.e. os=redhat)
+   - one explorer returns one fact
+   - facts via environment variables
+   - proposal steven: UPPER_CASE
+      - __fact_os (Nico)
+
+   - DEFINE path_to_explorer
+   - DEFINE explorer
+--------------------------------------------------------------------------------
+
+

doc/dev/logs/2011-02-03

@@ -0,0 +1,50 @@
+Steven:
+
+- cdist-deploy-to = main script
+- all user usable variables are defined using export __var=...
+- cdist-explorer return one line of output (or empty)
+- cdist-manifest-init: generates what the user defined to be configured on target host
+- HACKERS_README == starting point (until 1.0)
+   - [12:49] kr:cdist% __cdist_config=$(pwd -P)/conf __cdist_target_host=ikq02.ethz.ch cdist-manifest-init 
+- cdist_tree_wrapper == non-user-binary => libexec
+- conf/explorer collection of explorer
+- config-layout: current status of configuration
+   - needs to go into manpage
+- TODO: contains most up-to-date todo stuff, mid-term
+- ROADMAP: next steps
+- Documentation must be bit better than excellent at first release
+- test/: ignore (braindump and pre-braindump)
+- conf/
+   cache: generated
+   explorer: ok => contains explores
+   lib: deprecated (does not exist)
+   manifests: entry point for config2host
+   types: cdist-types(7)
+- alternative names for explorer:
+   - probe
+   - fact
+   - ...
+   - => STEVEN TO DECIDE
+- explorer / execution:
+   - see explorer-implementation-ideas.TO_FINISH_AND_DELETE
+
+Todo:
+- cdist-preprocess:
+   - fix call to cdist-build-explorer and transfer explorer to target host
+- cdist-manifest-init/ cdist_tree_wrapper:
+   - fails on second run => use different cache! (old cache exists until new is valid!)
+- .source in cdist_tree_wrapper records wrong source!
+- cdist-config:
+   - use export to mark user available variables!
+- doc/man/* => defined in TODO
+
+
+Future:
+- ids containing slashes for easier use in types?
+   - a) __file abc --source /path/from/abc --destination /path/to/abc
+   - b) id=abc
+        __file $id --source /path/from/$id --destination /path/to/$id
+   - c) __file abc --sourcedir /path/from/ --destination_dir /path/to/
+      - type file defines that id is implicitly used when --...dir variants used
+   - d) __file /path/to/abc --source ? --destination ?
+      - reusing id with slashes would be nice

doc/dev/logs/README

@@ -0,0 +1 @@
+Logfiles of discussions

doc/dev/logs/stevens_ideas

@@ -0,0 +1,7 @@
+Template-Verzeichnis
+   mit Definitionen für File
+      User kann globales Template verändern
+      copy und dann neues default
+      Defaults kopiert
+
+   Global nur Attribute, keine Werte