67 lines
1.7 KiB
Text
67 lines
1.7 KiB
Text
|
Meeting with: Steven, Thorsten, Nico
|
||
|
|
|
||
|
|
Problem: execute my code only if somebody else's changed something.
|
||
|
|
|
||
|
|
Proposals:
|
||
|
|
|
||
|
|
1) Introduce new binary (Steven)
|
||
|
|
|
||
|
|
gencode:
|
||
|
|
|
||
|
|
if has_changed __file/etc/nginx.conf; then
|
||
|
|
echo mycode
|
||
|
|
fi
|
||
|
|
|
||
|
|
2) Use -f plus new variable to cover .cdist/has_code:
|
||
|
|
|
||
|
|
if [ -f $global/objects/__file/etc/nginx.conf/$has_code ]; then
|
||
|
|
echo mycode
|
||
|
|
fi
|
||
|
|
|
||
|
|
And $has_code resolves to .cdist/has_code to cover the .cdist
|
||
|
|
directory.
|
||
|
|
|
||
|
|
3) Create a new tree that contains changed objects
|
||
|
|
|
||
|
|
if [ -e $global/changed/__file/etc/nginx.conf ]; then
|
||
|
|
echo mycode
|
||
|
|
fi
|
||
|
|
|
||
|
|
4) Use a \n seperated list
|
||
|
|
|
||
|
|
if grep -q __file/etc/nginx.conf $global/changed; then
|
||
|
|
echo mycode
|
||
|
|
fi
|
||
|
|
|
||
|
|
X) General problem (add to FAQ):
|
||
|
|
|
||
|
|
When having "do something only if somebody else did something"
|
||
|
|
it is possible that users get confused, because code will not
|
||
|
|
be executed.
|
||
|
|
|
||
|
|
This may especially happen in code development:
|
||
|
|
|
||
|
|
a) User creates __file/etc/nginx.conf
|
||
|
|
b) User creates a new type __nginx that restarts
|
||
|
|
nginx, only if __file/etc/nginx.conf changed.
|
||
|
|
But __file/etc/nginx.conf has already been deployed
|
||
|
|
and thus will never be restarted.
|
||
|
|
--------------------------------------------------------------------------------
|
||
|
|
|
||
|
|
Introduce exclude/conflicts attribute for types?
|
||
|
|
|
||
|
|
Handling in cdist vs. handling in the types themselves?
|
||
|
|
|
||
|
|
Examples: __file, __link, __directory
|
||
|
|
|
||
|
|
Need to handle errors on low level for those anyway.
|
||
|
|
|
||
|
|
Conclusion: Wait until we need exclude in a different type.
|
||
|
|
|
||
|
|
Pro:
|
||
|
|
Throw error as soon as possible without touching the target.
|
||
|
|
|
||
|
|
Contra:
|
||
|
|
No needod for most cases.
|
||
|
|
Very controversal for stuff like __package and __package_gem
|
||
|
|
for instance: rails; Should those two conflict or not?
|