On Oct 20, 2010, at 8:00 AM, Martin Langhoff wrote:

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

I wouldn't call it unreasonable.  I would call it "lack of a really cool 
feature".

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

Except if you look through the definitions in the class it shouldn't be too 
manually write rules that do the opposite.
Second, you don't need to do this for config files in directories managed with 
"purge".
Third, if you're in a hurry, you don't actually need to reverse every step.  
You only need to disable anything that's active.  This isn't a best practice, 
but it does work if you're careful.

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

I would go farther and say that it could be very very unclear.  Exec is a 
trivial example and is trivial to fix by adding another parameter.

A much nastier example is File.  I've been managing a config file.  The file 
existed before and File replaces it.  Later the file is replaced by something 
other than Puppet.  File dutifully replaces the file again.  Which file should 
puppet restore?


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

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

Reply via email to