Puppet users - Jul 2007 - Groping for a design pattern on negative configuration elements.

Situation:

1) Machine A was configured with class X.
2) Class X adds a bunch of files, services, etc...
3) User now wants to remove class X from the system.

Questions:

A) What is the proper method for applying class removal logic such
that the system is not burdened with a ton of extra overhead checking
for things that don''t exist?

B) How should this be done anyway?

My gut reaction is to have something like the following:

class A {
  define install_A {
    file { "foo": ensure => present }
  }
  define remove_A {
    file { "foo": ensure => present }
  }
}

Then call remove_A in all cases where you don''t want to have
''foo'' present.

But....technically, this only needs to be successfully called once and
I don''t want to spend the cycles checking for the existence of
''foo''
once it has been removed.

And yes, this is a simplistic example.  Think of an example with a
good 20 elements under the define and it''s more indicative of the hard
case.

Thanks,

Trevor

On Jul 5, 2007, at 3:41 PM, Trevor Vaughan wrote:
> Situation:
>
> 1) Machine A was configured with class X.
> 2) Class X adds a bunch of files, services, etc...
> 3) User now wants to remove class X from the system.
>
> Questions:
>
> A) What is the proper method for applying class removal logic such
> that the system is not burdened with a ton of extra overhead checking
> for things that don''t exist?
>
> B) How should this be done anyway?
There are basically two ways to do it -- the method you propose  
below, which is quite expensive, as you say, both in terms of  
execution and development time; the other option is to keep state  
information about the configuration, so that puppetd can notice  
changes in the configuration, then you''d set a policy saying that  
when resources are removed from the configuration they should be  
removed from the host.

That wouldn''t be all that difficult to do, but it''s not
something you
can do at the moment.
> My gut reaction is to have something like the following:
>
> class A {
>   define install_A {
>     file { "foo": ensure => present }
>   }
>   define remove_A {
>     file { "foo": ensure => present }
>   }
> }
>
> Then call remove_A in all cases where you don''t want to have
''foo''
> present.
>
> But....technically, this only needs to be successfully called once and
> I don''t want to spend the cycles checking for the existence of
''foo''
> once it has been removed.
>
> And yes, this is a simplistic example.  Think of an example with a
> good 20 elements under the define and it''s more indicative of the
hard
> case.
You''d be better off just having a global switch, so that you had  
ensure => $install, and you could set $install to true or false.   
This wouldn''t work for all resources, though -- you can''t
delete
services, for instance, you can only stop them.

  --
  Nothing is impossible for the man who doesn''t have to do it himself.
  -- A. H. Weiler
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com