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.
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.... > > Thanks, > Mohamed. > > On Mon, Apr 25, 2011 at 1:56 AM, pzi <pzi...@gmail.com> wrote: > > File content is just a small part of what puppet classes generally do. > > Average module if coded properly will include number of operations > > like starting/configuring services, cron jobs, editing files, > > installing packages, etc. and I think the only way to satisfy that > > average change control 'revert' is to code the reverse operation while > > you code the change. > > I would compare it to rc init scripts what have 'start' and 'stop' > > operations. It is all a matter of coding standards and defensive > > design. > > -Peter > > > On Apr 24, 5:12 am, James Turnbull <ja...@puppetlabs.com> wrote: > >> Mohamed Lrhazi wrote: > >> > For each change to production systems, one has to submit a script > >> > detailing what changes will be made and how to revert them back.. I > >> > was wondering if any of you, who implemented something similar, would > >> > care to share how they did it. > > >> There is no such thing as rollback. :) > > >> I wrote roll in and roll out manifests and tested both. The roll in > >> manifest made the required packages. The roll out manifest reversed > >> those changes. > > >> > Simply reverting puppet's own config to a previous repository version > >> > would not be enough in most cases, as it would not necessarily involve > >> > restoring overwritten files on the clients, if those files were not > >> > originally generated from puppet itself. > > >> Files can be backed up remote file buckets. > > >> > I guess Puppet's buckets would be involved in the answer, but my > >> > understanding is that they are not documented yet, correct? is such a > >> > feature planned for upcoming releases? > > >> It is documented. > > >>http://docs.puppetlabs.com/references/2.6.7/type.html#filebucket > > >> The feature already exists. > > >> Regards > > >> James > > >> -- > >> James Turnbull > >> Puppet Labs > >> 1-503-734-8571 > > > -- > > 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 > > athttp://groups.google.com/group/puppet-users?hl=en. -- 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.
