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/-/uPGycpyKnEsJ. 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 Thu, Jul 5, 2012 at 4:45 PM, gilbertc777 <gilbertc777@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-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.
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.