define second stage provider run
Signed-off-by: Nico Schottelius <nico@yoda.schottelius.org>
This commit is contained in:
parent
c1b548da49
commit
5da17d9805
1 changed files with 35 additions and 3 deletions
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue