Adding then removing SW - best practices?

[JonY]

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?

[Garrett Honeycutt]

> --
> 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
> <mailto:puppet-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/7cf584ad-b697-4904-8428-9750a1444a93%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/7cf584ad-b697-4904-8428-9750a1444a93%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

Hi,

If you take the approach of immutable systems, you would just provision
new systems that do not have the software, transition to using them and
then remove the old systems altogether.

Getting into the practice of regularly rebuilding your hosts ensures
that your provisioning process + configuration management is actually
working.

Best regards,

-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[JonY]

I get the rationale of an 'immutable system' but I don't have the privilege of replacing these. They are field-deployed in sensitive locations. 

On Sunday, October 26, 2014 6:11:56 PM UTC-7, Garrett Honeycutt wrote:

On 10/26/14 5:18 AM, 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

> <mailto:puppet-users+unsub...@googlegroups.com>.

[Thomas Müller]

Am Sonntag, 26. Oktober 2014 13:18:44 UTC+1 schrieb JonY:

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. 

 

You would need to have a "uninstall module" or a module which supports sort of  "ensure => absent" to remove things. After some time when all systems got the change you can remove the module. IMHO this is the puppet style of removing.

- Thomas

[Brian Morris]

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 

[Trevor Vaughan]

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

--

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.

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

[JonY]

I've been using 'anti-classes' up to now.. hoping for a better way.. alas...

[Aaron Grewell]

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