# Revision history [back]

Puppet DSL is the same regardless of the underlying OS (though windows and *nix variants have obvious differences in the DSL you would craft) which gives you portability. Upgrading the bash package on Solaris, Debian, and RHEL is the same:

puppet apply -e "package {'bash': ensure => latest}"

The reporting is the same between nodes, and hence portable, so a Solaris and Debian node that fail to install both clearly contain the same error, plus the instance-specific error messages. You have everything you might need to debug without needing to decipher similar-but-not-quite log messages to determine if you were successful.

Because the DSL is idempotent, you can apply the same DSL multiple times without concern about whether or not changes may already be present and will my customized script with little to no error checking do something crazy like insert duplicate lines in this .conf file oh god will I have a job tomorrow? (we've all been there!) You just tell it the state you desire and it makes it so, doing nothing if that is already the system state.

An additional, but potentially smaller, benefit is that puppet simply applies. It handles dialogs for you (compare yum install ... versus puppet apply with a package resource, or vi ... vs an apply that modifies a config). IMO this makes bootstrapping a node very simple, even when that node will never talk to a master.

The DSL provides documentation on the state you specified. If you keep track of all the OS-specific configuration elements, you need to provide additional documentation on the state. Puppet makes recreating your state later - on the next major or minor release, or on a different OS - much easier and very simple to diagnosis if there are failures, as the DSL itself is self-documenting.

You can also check the puppet code into revision control to track the change in your desired state over time. This can often be done with build instructions but is not always as straight forward.