cdist-types(7)
===============
Nico Schottelius <nico-cdist--@--schottelius.org>


NAME
----
cdist-types - Functionality bundled


DESCRIPTION
-----------
A cdist type describes some kind of functionality.
Types can be run from manifests.
It is recommeneded to prefix all types with two
underscores, because types will be executed and
thus you prevent collisions with real binaries
(like "file").

This document is a brainstorming document, on how to integrate types.

Proposed/discussed structures:

1) 2010-11-02
   $basedir/$type/
      properties/
         name/
            required # required | optional
         choices  # \n liste
            

      meta/
         default (shell script)
      types/
         pukman/

2) 2010-11-09

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.



--------------------------------------------------------------------------------
type layout:

   <name>/
      config   # binary that is called to adjust cconfig tree
      change   # binary that is called on the remote host?
--------------------------------------------------------------------------------
Scope of code execution on the client

   It should be assumed that the clients are pretty dumb
   and thus do not have high level tools like python
   installed.

   If a type requires specific tools to be present
   on the target, there must be another type that
   provides this tool and the first type must create
   an object of the specific type.

   If the generated code fails on the client, it must
   print diagnostistic messages on stderr and call
   "exit 1", so the configuration is aborted.

--------------------------------------------------------------------------------
   - have required and optional arguments
   - are independent of hosts
   - may make use of other types to realise a new type
      - how to overwrite stuff?
      - overwrite in own tree?
         - needs knowledge of inherited provider
            - similar to current situation in puppet,
              but more like reusable defines
   - or may implement some functionality on their own 

--------------------------------------------------------------------------------
Differences manifests vs. types


                     manifests               types

main purpose         map config to host      provide functionality
can change config    no (prevent conflicts)  yes (allow inheritance)
specificness         site specific           (globally) reusable


SEE ALSO
--------


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).