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+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.
