We wanted a push based configuration management, that actually had reasonable error messages. We were looking at puppet, but the undecipherable error messages were such a pain!
We searched and found cdist. We're very much enjoying it. The reasons he lists for switching against Puppet resonated with me very much.
Plus, it's written in Python3, which might be a turn off for some, but it's a pretty cool demonstration that python3 is making its way in the wild.
It appears that all the target configuration is done the old fashioned way with shell scripts run on the target machine. The Python3 code runs on the hose machine and decides what scripts to run where. The code base (according to sloccount) is 55% python and 45% shell.
I looked through the docs, but couldn't find anything interesting regarding exchanging data between nodes. Everything seems to be isolated and the only real exchange seems to be possible in local script generators. How do you do stuff like "find all running frontend nodes and put them into this config file", or "find a database node and create a config with credentials valid for that node" using cdist?
I haven't looked at puppet in a while, but I think this feature is only possible in chef, where each node can execute search queries on the chef server. It is actually one of the reasons I prefer chef to puppet.
I guess since the developers of the tools are coming from the puppet world, they did not think about implementing it.
Wether this kind of feature should be implemented in the CM tool is another debate :)
Puppet provides a mechanism called Exported Resources allowing nodes to provide bits of config for use by other nodes. For example I presently export Nagios check resources for webservices on my web nodes, which are collected by my Nagios server for building it's config.
Presumably once they ssh in they can install python in a virtualenv or do anything they want basically. I would imagine this would be only a bootstrap problem.
A few people have clarified what runs where, and you're ignoring them with an irrelevant and misleading point. To clarify, Python is not used on the slaves.
I wanted to know if "doesn't run on the target" means a bootstrap dependency only. After the target has been setup for configuration I don't see a reason why Python, Ruby or anything can't be installed in a sand-boxed environment.
We searched and found cdist. We're very much enjoying it. The reasons he lists for switching against Puppet resonated with me very much.
Plus, it's written in Python3, which might be a turn off for some, but it's a pretty cool demonstration that python3 is making its way in the wild.