You're be right with "a single type for all implementations" which makes the usage more intuitive. But there also exists the opposite: __package_* types as example. It's a bigger mess to have many…
any real world example why one should need or use __service?
I can only think one usecase, but this isn't supported by cdist.
__some_type foo --doing something
onchange='__some_type/foo'…
Difference between the different __package_* and __service_* types I can see are:
The different package implementations
- have quite a bit of code,
- take different arguments.
While for service…
I can see three real-world use cases:
- you install a package and want to make sure that the service is running after installation,
- you need to stop a service to uninstall a package,
- you changed…
I require to restart/reload a service. For my case, I generate a dns configuration and reload the dns daemon, so the changes will be applied. Also referring to the manual, the chapter "Drive into…
@matze You raise some valid points, but they all show shortcomings of cdist, don't they?
__servicebeing a type is unfortunate for types which do their changes in code-remote and not through…
My suggestion is how I made the __systemd_service type (see !844). States are sure, because this is implemented by cdist's design.
The thing you referred from puppet looks like hooks which will…
I've looked around why there's a special __config_file type, but the reason is to reload a daemon configurations if the content of the current file changes. This is done by passing a command, which…
- rationale: side effect
- desirable to mute: yes
- support for creating mr to support scripts that don't output stdout: yes
Just checked the code and I am a bit confused: we have return_output and depending on PIPE. Best thing is though that I can use git blame to blame @poljakowski for it:
9703e0f08…
mentioned in merge request !871
mentioned in merge request !872
closed via commit ea3bd14d8b377818a16578bd5032a853188baeec
closed via merge request !872
closed via commit 888cf54d99c2dda1d399e4851ee84ef272dc64c7
mentioned in commit 888cf54d99c2dda1d399e4851ee84ef272dc64c7