On Tuesday, May 7, 2013 8:13:39 AM UTC-5, denmat wrote:
No, puppet is not transactionable. There is also no simple way to do it in
puppet and running noop first is no guarantee that the run will succeed.
And this isn't so much an issue with Puppet as with the underlying system
tools. Depending on the circumstances and environment, package rollbacks
may not even be possible. (For example, if the original package is no
longer available from any of the configured repositories.) Also, to the
extent that package management may trigger embedded scripts to run, those
scripts cannot be un-run.
With some effort, it should be possible to design your manifests so that
package management progresses in a fixed sequence, and any failure along
the way prevents further resource modifications, but rollback is another
Version control may help you out to 'roll back' but it would be messy
depending on changes. Traditional methods of snapshoting disk or
backup/restore can be wrapped around it (never done that myself).
Yes, I think that whether you use Puppet or some other tool, if you truly
need to implement rollback then your best bet is to use file systems and
underlying configuration supporting snapshotting, so that you can roll back
by reverting to a snapshot. Do note that such an event would roll back the
entire file system, however, which cannot safely be done to a live
filesystem. You might be able to automate the process, but the system
would need to be taken out of service while the reversion was performed.
Any work in progress and any data not stored remotely would be lost.
Furthermore, if the snapshot were recorded of a live system, then it is
virtually certain that restoring it brings the filesystem to a state that
is inconsistent with the then-running processes. The system may be able to
recover from that without manual intervention, but it's not clean.
Rspec testing can help you out a bit in testing as of course so can other
pre deployment testing.
If the client doesn't like 'always roll forward' then puppet might not
float their boat.
If all you really want to be able to roll back is the set of installed
packages, then you could perhaps wrap Puppet in some custom fixture that
records a complete package list before the run, with versions, recognize
failed runs, and removes / downgrades packages afterward as necessary. Run
that out of cron, instead of running the agent as a daemon.
Really, though, that's a whole lot more trouble than it's likely to be
worth. Were I you, I would try to talk the client down to something more
manageable (and safer).