- It handles dynamic host environments like AWS badly. Puppet's SSL infrastructure gets often confused when hostnames and IP addresses of servers change and you can't disable certificate checking completely, even if you don't need it. As a result, Puppet sometimes dies and can't continue until you manually resolve the certificate issue (usually by deleting the client certificate and letting it regenerate). This can be helped by using fixed certificate names, but I've still seen these problems occur and they shouldn't.
- The dependency based configuration model gets very hard to manage when you keep adding new features to servers over time. Unless you reinstall the server from scratch every now and then to test it, you're bound to make subtle mistakes in the dependencies. This will bite you the next time the server is being fully reinstalled (e.g. after EC2 instance termination), as Puppet needs to run multiple times to satisfy the dependencies and this will take hours (because it runs in 30 minute intervals).
Because of these problems, I've been considering switching to Chef for a while but haven't gotten around to it yet.
We have lots of automated build procedures which I'm hoping to eventually fold into Chef.
I looked into the both of them for managing a couple of personal machines, and decided against Chef because of the very heavy stack.
What I found really lacking, however, was the bootstrap process. I want a way to provision a machine from the ground up, automated installation, followed by insertion into the managaed network, and then management following my policies.
Trying to get this into place was quite difficult, and I'm currently stalled in my project. Does anyone have any insights?
I think the general gist for both Chef and Puppet is you'll need to build the machine, build Chef/Puppet and their dependencies, then you can automate the rest of the build using them.
Also, you may want to check out FoodFight, the bi-weekly Chef Community podcast http://foodfightshow.org