I've begun to shift to anticlass-by-default. This is driven by the need to provide documentation to auditors and the like. I foo::remove by default, then foo::install as needed (wrapped in appropriate logic to avoid resource conflicts).
On Monday, October 27, 2014 1:21:55 PM UTC-7, JonY wrote: > > I've been using 'anti-classes' up to now.. hoping for a better way.. > alas... > > > On Monday, October 27, 2014 11:17:12 AM UTC-7, Trevor Vaughan wrote: >> >> One day, long ago in 2008, there was a discussion on anti-classes: >> http://comments.gmane.org/gmane.comp.sysutils.puppet.user/5884. >> >> Yeah, they're still irritating, but I don't really know how else to do it. >> >> init.pp ( $enable => true ) ==> Main Class >> init.pp ( $enable => false ) ==> Anti Class >> >> Trevor >> >> On Mon, Oct 27, 2014 at 11:54 AM, Brian Morris <nomadic...@gmail.com> >> wrote: >> >>> This could be done in a stateful fashion. Start with a facter like this: >>> >>> Facter.add(:apache_exists) do >>>> >>>> confine :osfamily => "Debian" >>>> >>>> setcode do >>>> >>>> if Facter::Util::Resolution.exec("dpkg -l | grep apache2 | grep -v >>>>> apache2-utils | grep ^ii") >>>> >>>> "true" >>>> >>>> end >>>> >>>> end >>>> >>>> end >>>> >>>> >>> ... and then, in a manifest, reference the facter to see if it is true: >>> >>> if ( $::apache_exists ) { >>>> >>>> do something, >>>> >>>> } >>>> >>>> >>> >>> Brian >>> >>> >>> On Sunday, October 26, 2014 5:18:44 AM UTC-7, JonY wrote: >>>> >>>> Let's say that I'm deploying a steady stream of identical hosts. Each >>>> has some piece of SW on it that's managed by Puppet. I continue to >>>> (regularly) add to and maintain this group over time. >>>> >>>> Day comes when this SW is no longer required. >>>> >>>> So I remove the module from Puppet to prevent it being included on >>>> future hosts in this group. >>>> >>>> "What about the existing hosts?" I ask. >>>> "Add a module to remove the SW" I think. >>>> "What about the future hosts? Won't this seem a bit odd to tell puppet >>>> to remove SW that was never installed?" I wonder. >>>> "Puppet is idempotent!" says the FM. >>>> "Ok - but it still seems amiss. To a 'distant observer' it would seem >>>> an odd practice." says I. >>>> >>>> Should I break up the 'before' and 'after' hosts into separate groups / >>>> environments? I use an ENC to manage the modules. Maybe a DB entry to >>>> indicate who gets the extra module? >>>> >>>> Some other pathway? >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Puppet Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to puppet-users...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-users/825cb051-76b9-4353-8ee7-20c7b81d2896%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/puppet-users/825cb051-76b9-4353-8ee7-20c7b81d2896%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> tvau...@onyxpoint.com >> >> -- This account not approved for unencrypted proprietary information -- >> > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/eaa2c46c-8581-4a39-9725-53dee3364d73%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
