rename provider to type
Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
parent
6f576889e3
commit
78b10e0ea6
1 changed files with 22 additions and 24 deletions
|
@ -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
|
Loading…
Reference in a new issue