pedro/cdist
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

rename provider to type

Browse source 
Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
Nico Schottelius 2011-01-17 22:44:34 +01:00
parent 6f576889e3
commit 78b10e0ea6
1 changed files with 22 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

46
doc/internal/provider-integration → doc/internal/type-integration
View file

@ -1,6 +1,4 @@
This document is a brainstorming document, This document is a brainstorming document, on how to integrate types.
on how to integrate providers. Providers
had been "type" in previous discussion.
Proposed/discussed structures: Proposed/discussed structures:
@ -14,7 +12,7 @@ Proposed/discussed structures:
meta/ meta/
default (shell script) default (shell script)
providers/ types/
pukman/ pukman/
2) 2010-11-09 2) 2010-11-09
@ -43,57 +41,57 @@ attributes.
-------------------------------------------------------------------------------- --------------------------------------------------------------------------------
provider layout: type layout:
<name>/ <name>/
config # binary that is called to adjust cconfig tree config # binary that is called to adjust cconfig tree
change # binary that is called on the remote host? change # binary that is called on the remote host?
-------------------------------------------------------------------------------- --------------------------------------------------------------------------------
cdist view on providers: cdist view on types:
How providers are integrated/run: How types are integrated/run:
First stage: First stage:
- If cdist encounters provider in manifest, - If cdist encounters type in manifest,
a wrapper script is run, that creates a a wrapper script is run, that creates a
new entry in the cconfig database and adds new entry in the cconfig database and adds
attribute values. This defines a cconfig attribute values. This defines a cconfig
tree, that may look as follows: tree, that may look as follows:
<hostname>/<provider>/<id>/<parameters>: <hostname>/<type>/<id>/<parameters>:
myhost/__file/cdist_bin/source myhost/__file/cdist_bin/source
myhost/__file/cdist_bin/destination myhost/__file/cdist_bin/destination
... ...
- In this stage, no conflicts may occur, as - In this stage, no conflicts may occur, as
no provider code has been called (i.e. only no type code has been called (i.e. only
manifests, which map config to hosts is manifests, which map config to hosts is
applied). applied).
Second stage: Second stage:
- The "manifest" script of every used provider - The "manifest" script of every used type
(i.e. the manifests created at least one object) (i.e. the manifests created at least one object)
is called, which again is able to call other is called, which again is able to call other
providers. All created objects may also be modified types. All created objects may also be modified
by the provider. by the type.
For instance a "httpd" provider may call the For instance a "httpd" type may call the
"webroot" provider with --path / ... "webroot" type with --path / ...
# FIND CASE WHERE SENSEFUL => look through # FIND CASE WHERE SENSEFUL => look through
current puppet config current puppet config
- The newly created objects are merged back into - The newly created objects are merged back into
the existing tree. No conflicts may occur during the existing tree. No conflicts may occur during
the merge, because this would implicit that the the merge, because this would implicit that the
provider conflicts with other providers. type conflicts with other types.
The idea of this that a provider may expand another The idea of this that a type may expand another
provider with functionality, but may need to adjust type with functionality, but may need to adjust
("overwrite") settings from the original provider. ("overwrite") settings from the original type.
Third stage: Third stage:
- Cdist calls the "gencode" binary of the providers - Cdist calls the "gencode" binary of the types
for every created object. This binary should create for every created object. This binary should create
code to be executed on the target on stdout. code to be executed on the target on stdout.
@ -118,10 +116,10 @@ Scope of code execution on the client
and thus do not have high level tools like python and thus do not have high level tools like python
installed. installed.
If a provider requires specific tools to be present If a type requires specific tools to be present
on the target, there must be another provider that on the target, there must be another type that
provides this tool and the first provider must create provides this tool and the first type must create
an object of the specific provider. an object of the specific type.
If the generated code fails on the client, it must If the generated code fails on the client, it must
print diagnostistic messages on stderr and call print diagnostistic messages on stderr and call