cdist-mirror/doc/internal/logs/2010-11-09

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