Puppet users - Apr 2011 - How do you implement "revert changes'

I forgot to think about a little detail, while introducing Puppet to
our environment :)

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.

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.

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?

am currently thinking that our only option would be to write and run
scripts to backup the specific files any change would affect, prior to
running "puppet agent --no-noop", so the revert step would be to run
another script to restore the backups, restart services...

Thanks a lot,
Mohamed.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 04/18/2011 11:22 PM, Mohamed Lrhazi wrote:
> I forgot to think about a little detail, while introducing Puppet to
> our environment :)
> 
> 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.
> 
> 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.
> 
> 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?
> 
> am currently thinking that our only option would be to write and run
> scripts to backup the specific files any change would affect, prior to
> running "puppet agent --no-noop", so the revert step would be to
run
> another script to restore the backups, restart services...
Filebucket does work for this purpose already. There should be a man
page (I know there is one in the Debian packages).

Doing this in a scripted fashion may be tricky, though. It will probably
involve parsing agent logs.

HTH,
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks Felix.... But how is Filebucket currently used? Is there a
"puppet agent --restore" functionality that I missed?


On Tue, Apr 19, 2011 at 3:20 AM, Felix Frank
<felix.frank@alumni.tu-berlin.de> wrote:
> On 04/18/2011 11:22 PM, Mohamed Lrhazi wrote:
>> I forgot to think about a little detail, while introducing Puppet to
>> our environment :)
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> am currently thinking that our only option would be to write and run
>> scripts to backup the specific files any change would affect, prior to
>> running "puppet agent --no-noop", so the revert step would be
to run
>> another script to restore the backups, restart services...
>
> Filebucket does work for this purpose already. There should be a man
> page (I know there is one in the Debian packages).
>
> Doing this in a scripted fashion may be tricky, though. It will probably
> involve parsing agent logs.
>
> HTH,
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 04/19/2011 08:55 PM, Mohamed Lrhazi wrote:
> Thanks Felix.... But how is Filebucket currently used? Is there a
> "puppet agent --restore" functionality that I missed?
No, as a matter of fact, you missed the whole "filebucket" binary ;-)

What I do interactively a lot is

filebucket -l get <md5>
and occasionally
filebucket -l restore /some/file <md5>

I get the md5sums from my agent log. The -l has filebucket use the local
clientbucket (which requires a puppet.conf entry to use the correct
location).

Cheers,
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <pzi123@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+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.