113 lines
3.3 KiB
Text
113 lines
3.3 KiB
Text
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).
|