I'm not using much at the moment, but we have looked at using Puppet and Chef to do interrelated sets of configuration changes across our data center. Got exposed to a little vendor training (not as much as I would have liked).
My impressions: both very powerful, similar in capability, very different in approach to automation. Puppet seems to put a greater emphasis on state over change (the engine makes changes to affect or restore a state in a node or nodes you have specified). The DSL Puppet uses was easier for our non-developers (especially our operations people) to pick up. Chef seems to put a greater emphasis on change over state (you specify a set of changes you would like to make, the engine makes those changes, achieving your end state). Our developers found Chef's basis in Ruby easier to understand. I have oversimplified the state vs. change dichotomy, but I wanted to try and give you a flavor for how the two differ.
In terms of the vendors themselves, both are very easy to work with. Puppet has a lot to offer if you use their enterprise product. Sounds like you are focusing on the open source versions, so no real advantage there.
I agree with others. Figure out what it is you want to automate (not broadly, but with some specificity), figure out how much effort you are willing to expend to automate those tasks or functions, then evaluate your options. Neither Puppet nor Chef is an end-all be-all. They (and other automation tools) are part of a larger tool chain (for example: other CM tools, continuous integration tools, QA/testing tools, monitoring tools, even backup tools). The first question is not which tool but where in your tool chain you use them.
Oh, I have been hearing about another option in this area recently: Ansible. Sounds interesting, but I haven't had much time to read up on it.
