cdist/doc/internal/provider-integration
Nico Schottelius 5da17d9805 define second stage provider run
Signed-off-by: Nico Schottelius <nico@yoda.schottelius.org>
2011-01-15 18:21:07 +01:00

93 lines
2.9 KiB
Text

This document is a brainstorming document,
on how to integrate providers. Providers
had been "type" in previous discussion.
Proposed/discussed structures:
1) 2010-11-02
$basedir/$type/
properties/
name/
required # required | optional
choices # \n liste
meta/
default (shell script)
providers/
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.
--------------------------------------------------------------------------------
provider layout:
<name>/
config # binary that is called to adjust cconfig tree
change # binary that is called on the remote host?
--------------------------------------------------------------------------------
cdist view on providers:
How providers are integrated/run:
First stage:
- If cdist encounters provider in manifest,
a wrapper script is run, that creates a
new entry in the cconfig database and adds
attribute values. This defines a cconfig
tree, that may look as follows:
<hostname>/<provider>/<id>/<parameters>:
myhost/__file/cdist_bin/source
myhost/__file/cdist_bin/destination
...
- In this stage, no conflicts may occur, as
no provider code has been called (i.e. only
manifests, which map config to hosts is
applied).
Second stage:
- The "manifest" script of every used provider
(i.e. the manifests created at least one object)
is called, which again is able to call other
providers. All created objects may also be modified
by the provider.
For instance a "httpd" provider may call the
"webroot" provider with --path / ...
# FIND CASE WHERE SENSEFUL => look through
current puppet config
- The newly created objects are merged back into
the existing tree. No conflicts may occur during
the merge, because this would implicit that the
provider conflicts with other providers.
The idea of this that a provider may expand another
provider with functionality, but may need to adjust
("overwrite") settings from the original provider.