Re: [Puppet Users] Built in rollback features

[Brian Gupta]

On Thu, Jul 5, 2012 at 4:45 PM, gilbertc777 <gilbe...@gmail.com> wrote:
> Hi Everyone,
>
> I am relativly new to writing puppet modules, and am working to architecht
> our puppet implementation. One of the questions I have, is rolling back a
> puppet run. What are the best ways to accomplish this.
>
> For instance, if I add a module to manage autofs, apply it to a server, and
> then no longer want to manage autofs on the server, how would I make it so
> that I can roll the server back to the unconfigured state?
>
> Also, when managing local account using puppet, what are ideas to handle the
> following case:Users A, B and C are added to all our servers. After running
> for some time, we need to only remove User B.
>
> I have read on multiple blogs about having !classes, but I want to try and
> work towards using more of an industry standard and wanted to get other
> peoples opinions.

Puppet doesn't have any concept of rollback. You are declaring what
you want as your end result. Also bear in mind puppet only manages
resources that are in your manifests. (There are 10s of thousands of
objects on a default OS install that are unmanaged, if you consider
ever file, service, user or package that gets installed.)

One example:

If you had a manifest that didn't manage the user "testuser" and added
a resource to manage it, it would go from "unmanaged" to managed, and
create it if it didn't exist. If one were to roll back to a previous
manifest that didn't have "testuser", the user would still exist on
the system in an unmanaged state. In the puppet world if you want that
removed, you have to continue managing that resource, but ensure that
the resource in question is absent, or purged, using "ensure". e.g. -
"ensure => absent"

> Thanks!
> Chuck
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/uPGycpyKnEsJ.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

[Ryan Bowlby]

I tend to expose the ensure related resource attributes as parameters that can be specified at the node level:

class { "apache":

  package_ensure => "absent",

}

The natural evolution is to get to a point within the organization where reinstalling a host is no longer scary. If the provisioning process is working well you can likely do a rolling reinstall of the infrastructure to ensure against system "state drift". That's often much easier than attempting to write each module to support the arguably antiquated idea of rollbacks.

-Ryan

Hope Turnbull doesn't see this post, no more princess rape digressions. lol

On Thursday, July 5, 2012 1:45:13 PM UTC-7, gilbertc777 wrote:

Hi Everyone,

 

I am relativly new to writing puppet modules, and am working to architecht our puppet implementation.  One of the questions I have, is rolling back a puppet run.  What are the best ways to accomplish this. 

 

For instance, if I add a module to manage autofs, apply it to a server, and then no longer want to manage autofs on the server, how would I make it so that I can roll the server back to the unconfigured state?

 

Also, when managing local account using puppet, what are ideas to handle the following case:Users A, B and C are added to all our servers.  After running for some time, we need to only remove User B.

 

I have read on multiple blogs about having !classes, but I want to try and work towards using more of an industry standard and wanted to get other peoples opinions.

 

Thanks!

Chuck