|
|
|
@ -224,3 +224,140 @@ in the repository for such content: It allows you to
|
|
|
|
|
easily distinguish what is used by cdist and what is not
|
|
|
|
|
and also to store all important files in one
|
|
|
|
|
repository.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Perils of CDIST_ORDER_DEPENDENCY
|
|
|
|
|
--------------------------------
|
|
|
|
|
With CDIST_ORDER_DEPENDENCY all types are executed in the order in which they
|
|
|
|
|
are created in the manifest. The current created object automatically depends
|
|
|
|
|
on the previously created object.
|
|
|
|
|
|
|
|
|
|
It essentially helps you to build up blocks of code that build upon each other
|
|
|
|
|
(like first creating the directory xyz than the file below the directory).
|
|
|
|
|
|
|
|
|
|
This can be helpful, but it can also be the source of *evil*.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CDIST_ORDER_DEPENDENCY easily causes unobvious dependency cycles
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Let's see an example. Suppose you have special init manifest where among other
|
|
|
|
|
things you are assuring that remote host has packages `sudo` and `curl`
|
|
|
|
|
installed.
|
|
|
|
|
|
|
|
|
|
**init1**
|
|
|
|
|
|
|
|
|
|
.. code-block:: sh
|
|
|
|
|
|
|
|
|
|
CDIST_ORDER_DEPENDENCY=1
|
|
|
|
|
export CDIST_ORDER_DEPENDENCY
|
|
|
|
|
|
|
|
|
|
for p in sudo curl
|
|
|
|
|
do
|
|
|
|
|
__package "${p}"
|
|
|
|
|
done
|
|
|
|
|
|
|
|
|
|
Then you have some other special init manifest where among other things you are
|
|
|
|
|
assuring `sudo` package is installed.
|
|
|
|
|
|
|
|
|
|
**init2**
|
|
|
|
|
|
|
|
|
|
.. code-block:: sh
|
|
|
|
|
|
|
|
|
|
CDIST_ORDER_DEPENDENCY=1
|
|
|
|
|
export CDIST_ORDER_DEPENDENCY
|
|
|
|
|
|
|
|
|
|
__package sudo
|
|
|
|
|
|
|
|
|
|
Then you have third init manifest where you combine those two init manifests,
|
|
|
|
|
by including them:
|
|
|
|
|
|
|
|
|
|
**init**
|
|
|
|
|
|
|
|
|
|
.. code-block:: sh
|
|
|
|
|
|
|
|
|
|
sh -e "$__manifest/init1"
|
|
|
|
|
sh -e "$__manifest/init2"
|
|
|
|
|
|
|
|
|
|
The resulting init manifest is then equal to:
|
|
|
|
|
|
|
|
|
|
.. code-block:: sh
|
|
|
|
|
|
|
|
|
|
CDIST_ORDER_DEPENDENCY=1
|
|
|
|
|
export CDIST_ORDER_DEPENDENCY
|
|
|
|
|
|
|
|
|
|
for p in sudo curl
|
|
|
|
|
do
|
|
|
|
|
__package "${p}"
|
|
|
|
|
done
|
|
|
|
|
|
|
|
|
|
CDIST_ORDER_DEPENDENCY=1
|
|
|
|
|
export CDIST_ORDER_DEPENDENCY
|
|
|
|
|
|
|
|
|
|
__package sudo
|
|
|
|
|
|
|
|
|
|
In the end you get the following dependencies:
|
|
|
|
|
|
|
|
|
|
* `__package/curl` depends on `__package/sudo`
|
|
|
|
|
* `__package/sudo` depends on `__package/curl`
|
|
|
|
|
|
|
|
|
|
And here you have a circular dependency!
|
|
|
|
|
|
|
|
|
|
In the real world manifest can be quite complex, dependencies can become
|
|
|
|
|
complicated and circual dependencies are not so obvious. Resolving it can
|
|
|
|
|
become cumbersome.
|
|
|
|
|
|
|
|
|
|
**Practical solution?**
|
|
|
|
|
|
|
|
|
|
Instead of managing complex init manifests you can write custom types.
|
|
|
|
|
Each custom type can do one thing, it has well defined dependencies that will
|
|
|
|
|
not leak into init manifest. In custom type you can also add special explorers
|
|
|
|
|
and gencode.
|
|
|
|
|
|
|
|
|
|
Then, in init manifest you combine your complex types. It is:
|
|
|
|
|
|
|
|
|
|
* cleaner
|
|
|
|
|
* easier to follow
|
|
|
|
|
* easier to maintain
|
|
|
|
|
* easier to debug.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CDIST_ORDER_DEPENDENCY kills parallelization
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Suppose you have defined CDIST_ORDER_DEPENDENCY and then, among other things,
|
|
|
|
|
you specify creation of three, by nature independent, files.
|
|
|
|
|
|
|
|
|
|
**init**
|
|
|
|
|
|
|
|
|
|
.. code-block:: sh
|
|
|
|
|
|
|
|
|
|
CDIST_ORDER_DEPENDENCY=1
|
|
|
|
|
export CDIST_ORDER_DEPENDENCY
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
__file /tmp/file1
|
|
|
|
|
__file /tmp/file2
|
|
|
|
|
__file /tmp/file3
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
Due to defined CDIST_ORDER_DEPENDENCY cdist will execute them in specified order.
|
|
|
|
|
It is better to use CDIST_ORDER_DEPENDENCY in well defined blocks:
|
|
|
|
|
|
|
|
|
|
**init**
|
|
|
|
|
|
|
|
|
|
.. code-block:: sh
|
|
|
|
|
|
|
|
|
|
CDIST_ORDER_DEPENDENCY=1
|
|
|
|
|
export CDIST_ORDER_DEPENDENCY
|
|
|
|
|
...
|
|
|
|
|
unset CDIST_ORDER_DEPENDENCY
|
|
|
|
|
|
|
|
|
|
__file /tmp/file1
|
|
|
|
|
__file /tmp/file2
|
|
|
|
|
__file /tmp/file3
|
|
|
|
|
|
|
|
|
|
CDIST_ORDER_DEPENDENCY=1
|
|
|
|
|
export CDIST_ORDER_DEPENDENCY
|
|
|
|
|
...
|
|
|
|
|
unset CDIST_ORDER_DEPENDENCY
|
|
|
|
|