define second stage provider run

Signed-off-by: Nico Schottelius <nico@yoda.schottelius.org>
This commit is contained in:
Nico Schottelius 2011-01-15 18:21:07 +01:00
parent c1b548da49
commit 5da17d9805

View file

@ -42,20 +42,52 @@ attributes.
--------------------------------------------------------------------------------
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:
attribute values. This defines a cconfig
tree, that may look as follows:
conf/__file/cdist_bin/source
conf/__file/cdist_bin/destination
<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.