On the other hand, Ansible works well as simply a remote task runner (like Fabric). Salt is the one I have least experience with, but I had a conversation with the creator once and he seemed excited about the orchestration possibilities with Salt. If I understand correctly you can react to events that get triggered either manually or based on a condition on some other server you're managing. So both of these tools make it easy/natural to do something like run a rolling restart of a group of servers.
One thing that was somewhat unique about Ansible was it was designed for rolling updates as the initial use case, and the desire to solve deployment problems rather than just CM problems.
Everybody tends to view orchestration differently, so see our take:
http://www.ansible.com/blog/orchestration-you-keep-using-tha...
and
http://www.ansible.com/blog/2013/11/29/ansibles-architecture...
Ultimately, for us, it meant boiling back a lot of things to base concepts, and taking parts we liked from a lot of different things.
But is there a generation? I don't think so.
Some models make things a bit more or less flexible, or allow different capabilities.
IMO, it's three things:
* A push-by-default model rather than pull-by-default (that never made sense to me: option, maybe - default, HELL no).
* A focus on minimizing the dependencies (puppet has a ton of annoying unnecessary and attack-surface-increasing/ RAM-gobbling dependencies from the agent to the SSL authentication).
* Not using a DSL - just using YAML and an intentionally dumb templating language - helping to enforce a far cleaner separation between configuration and code (the divide can get muddied with puppet because its DSL is too powerful).