Re: [Puppet Users] Re: best practice for removing a module maintained resources from a system ?
On Thu, Oct 21, 2010 at 4:56 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: 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. OK - but putting (config) files into place is most of what we do with it right? We need to be able to manage them after putting them there, and that includes removing them. 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. Can you flesh out what other consequences you see? 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.
Re: [Puppet Users] Re: best practice for removing a module maintained resources from a system ?
On 10/21/2010 05:33 PM, Martin Langhoff wrote: On Thu, Oct 21, 2010 at 4:56 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: 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. OK - but putting (config) files into place is most of what we do with it right? We need to be able to manage them after putting them there, and that includes removing them. Managing whole config files is not puppet's strong suit at all. Puppet strives to implement as many providers as possible in order to keep you from the need to copy files to your nodes. Copying is actually a crude workaround from a designer's perspective. Theory aside, it's what most people use it for. But puppet is not supposed to be the ultimate file roller. In some cases, you may want to use a packaging system instead, or even a source control mechanism. 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. Can you flesh out what other consequences you see? None, *you* were the one complaining that purge and dpkg-controlled conf.d contents won't cooperate ;-) Seriously though, this is a matter of both taste and pragmatic choice you have to take based on the requirements at hand. Regards, 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.
Re: [Puppet Users] Re: best practice for removing a module maintained resources from a system ?
On Wed, Oct 20, 2010 at 12:09 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Oct 20, 2010 at 3:00 PM, Mohit Chawla mohit.chawla.bin...@gmail.com wrote: Except that some definitions may be gone. That's what worries me. Sure I can read the pp files as they are today. That's probably true for any tool or method. Unless it was in version control. Not true of packages under any modern packaging system, as per the example given. Which is an excellent reason for using packages with Puppet. There are other issues here, but I'm quite firmly of the opinion that if you need to manage a complex set of files related to a single function, and you want the features that a packaging system provides, you should build packages yourself and use Puppet to manage the state of that package. This doesn't solve every negation problem, but it significantly reduces the problem space. -- 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.
Re: [Puppet Users] Re: best practice for removing a module maintained resources from a system ?
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.
Re: [Puppet Users] Re: best practice for removing a module maintained resources from a system ?
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.
Re: [Puppet Users] Re: best practice for removing a module maintained resources from a system ?
On Wed, Oct 20, 2010 at 10:26 PM, Martin Langhoff martin.langh...@gmail.com wrote: Pretty fundamental feature :-) You don't have random scripts doing random business. If the puppet modules have been written nicely, I don't see any reason to be unable to go through them once, understand the structure, and work from that point. Even if they are not written nicely, you still have all the information in there, a bit of cleanup and you're on your way. You can have test runs, parse tests and all, just to know the state of the modules. Except that some definitions may be gone. That's what worries me. Sure I can read the pp files as they are today. That's probably true for any tool or method. Unless it was in version control. -- 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.
Re: [Puppet Users] Re: best practice for removing a module maintained resources from a system ?
On Wed, Oct 20, 2010 at 3:00 PM, Mohit Chawla mohit.chawla.bin...@gmail.com wrote: Except that some definitions may be gone. That's what worries me. Sure I can read the pp files as they are today. That's probably true for any tool or method. Unless it was in version control. Not true of packages under any modern packaging system, as per the example given. 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.
Re: [Puppet Users] Re: best practice for removing a module maintained resources from a system ?
On 10/18/2010 3:13 PM, jcbollinger wrote: On Oct 18, 5:19 am, Daniel Maherd...@witbe.net wrote: I am curious to know what is the best practice for removing a module (and the resources it maintains) from a system ? [...] I have occasionally written sub-modules to do the work of cleaning the resources away (ex. « webservice::no »), but this seems ridiculous, and is an administrative pain besides. What sorts of approaches might there be to make this for manageable ? 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. Perhaps you already understand this, but you do not grok Puppet until you know in your bones that Puppet is about achieving and maintaining *state*, and only incidentally about doing particular work. In this case, the state detail you achieve _and maintain_ is that the web service is not installed. If it is important to you that the service be absent from certain nodes, then why is it ridiculous for Puppet to maintain that? Exactly. If done right, this can be achieved by using purging on the proper directories (like /etc/http/conf.d) to keep away unmanaged contents. For the most things this obviates the need for a ::no class altogether. Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- 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.
