On Mon, Oct 18, 2010 at 9:13 AM, jcbollinger <john.bollin...@stjude.org> wrote: > I'm guessing you mean you have written sub-*classes* to do that job. > That is indeed the Puppet way to do it, and I don't find it at all > ridiculous.
As a puppet newcomer, that is a bit surprising, and IMO unreasonable. Imagine you are joining a puppet-using company. To "remove a class" from a server you now need to know all the files ever installed or managed by that class, since puppet started to be used there. There is no place (in puppet) to query that info! Hopefully some SCM was used, and used consistently. And you have to review by hand each revision. Joy! Compare/contrast this to what package mgmt tools do: they keep a small DB of what files they are tracking for each package on a given machine. A new version of the package needs only declare what files it has. The pkg manager will helpfully remove any stale files. From the PoV of the packager... I don't need to know what files any and all releases of this package installed -- it'd be impossible to know anyway. I don't need to remove any "possible" file ever installed by this package. Puppet manages many resource types, so this isn't trivial. For some resource types "what to do" won't be super clear. Puppet (currently doesn't, but ) should track what it manages, and help us remove it when appropriate. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
