diff --git a/doc/internal/provider-integration b/doc/internal/provider-integration index 1e25e77b..6fe483e9 100644 --- a/doc/internal/provider-integration +++ b/doc/internal/provider-integration @@ -42,20 +42,52 @@ attributes. +-------------------------------------------------------------------------------- +provider layout: + + / + 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 + ///: + + 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.