I (with advice from co-workers) decided against chef for two main reasons: Dependencies and complexity of implementation, and gut instinct from reading the lit

I (with advice from co-workers) decided against chef for two main reasons: Dependencies and complexity of implementation, and gut instinct from reading the literature. So I'm not surprised to see that it can be a little shaky. I also looked at cfengine3, and I liked the language, although I am not a fan of the "promise/promiser" terminology, the concept is consistently applied and as a result the language grammar is much simpler than puppet's. It basically came down to not being able to really choose between puppet and cfengine3 without actually trying them, and since I cared less about identifying the optimal tool than just getting stuff done I selected puppet arbitrarily. I rejected bcfg2 mainly because it seemed very server-oriented and although there was documentation for setting up the system there wasn't a lot of documentation about how to actually configure systems. I've revisited bcfg2 lately and the situation doesn't seem to have improved much. (eg I can't find a decent reference for the configuration language anywhere online. There's no equivalent to that puppet page that lists all the data types.) I also think the choice for XML as the configuration language is suboptimal but I could probably work with it. So we went with puppet, and although I left the position several months later (for unrelated reasons) we were already hitting some of those issues you mentioned. Incidentally, you don't even need the daemon to run puppet, so long as you're willing apply your own security model and distribution method (rsync over ssh, etc/).