On 10/20/2010 06:56 PM, Martin Langhoff wrote: > Except that some definitions may be gone. That's what worries me. Sure > I can read the pp files as they are today. > > - John had a webmail server class assigned to server Frodo. Service > apache must be running, an /etc/apache/conf.d/webmail.conf must be in > place. > > - Frodo is no longer a webmail server. John added a rule to disable > apache service. > > - Here I come new job! First task: set Frodo to be a moodle server. > New class has moodle dpkg, /etc/apache/conf.d/moodle.conf -- and > enables apache. > > Hell-O!
Adding the rule to disable apache service is not necessarily the right thing to do. Sure, the machine doesn't *need* to run apache anymore. Tell it so by removing the resource from the manifest (no longer include the webmail class). *Must* the machine no longer run a web server? Then, include a class that specifically disables apache. But then, that is what you (or the John from your example) has told puppet to maintain, so you need to think about it. I guess what you're getting at is this: No, puppet is not exactly good at "uninstall this now and from then on, don't care about it anymore". This is not what puppet has been conceived for, though. You're looking at a real problem, but not one puppet is (or should be) necessarily equipped to handle well (IMO). >> Second, you don't need to do this for config files in directories managed >> with "purge". > > How would you tackle the example above with 'purge'? Note that > /etc/apache/conf.d/ has other files too, provided by the apache dpkg > (and similar in /etc/httpd/conf.d on RH/Fedora machines). If you're on the purge train, you won't want your package manager to interfere with your conf.d directories. Instead, puppet will need the whole picture of what should be in the conf.d. Most puppet providers (package, host, mount, cron etc.) strive to do the opposite, and amend to a given state. Purge is a way to switch paradigms. If you choose to do that, be prepared to deal with the consequences. >> 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? > > I think we should at least be able to say "remove it when we no longer > mention it". Something like 'purgewhengone' => YesPlease > > Don't know if Puppet as it stands today keeps enough state for this. > > Any kind of 'restoreoriginal' would get into the problems you outline, > and then some more. Which "original"? It's an interesting train of thought. Filebucket may or may not be extended in some way that would allow such features. Note that this would be a solution for the file provider only. I'd be pleased to see your general idea extended in this or the devel forum. Cheers, Felix -- 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.
