On 04/25/2011 04:32 PM, pzi wrote: > Since most of the puppet activity is done on the root filesystem one > cool way to do it would be to use root ZFS on solaris or LVM on linux > and take a snapshot of that root filesystem before puppet run - then > rollback if needed.
I don't think that will fly - typically, you won't be able to just rewind a production machine to an arbitrary past state. I'm inclined to consider the occasions where you actually can do that as edge cases. > On Apr 25, 5:59 am, Mohamed Lrhazi <lrh...@gmail.com> wrote: >> Thinking about the "change" and the "reverted to change" as two >> different machine states, that both need to be coded in Puppet, is >> definitely right answer, I am starting to understand. No way puppet >> could figure out what how to get to the previous state. >> >> In my case I think all our initial changes, as we add more and more to >> puppet, will have a puppet-less 'revert" procedure: >> >> - Change via puppet. >> - Revert (the old way)t: >> for host in hosts: >> ssh to host >> run command1 >> run command2.... I can conceivably see use cases where that approach is much simpler and less error-prone than maintaining roll-back code in puppet. Just my 2c, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
