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
>
--
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/-/j6GaxxfnPR8J.
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.
