Puppet users - Aug 2007 - chain reactions? ...

Had a thought and I don''t think I see an obvious way to do this... so
for
instance:

All hosts are tagged with "baremetal" (i.e. those packages that are
deemed
necessary for proper running of a system)

host n1 is part of a group tagged as class foo.  Foo includes baremetal.

foo installs packages a, b, c and d

Now some time goes by and host n1 needs to be dedicated to another class
bar.  bar installs packages r, s and t and includes baremetal.

There are many package conflicts between the set for foo and the set for
bar.

(foo and bar are machine roles if you will).

Is this best to do with

class foo
  package {
    "A":
      ensure => installed;
    ...
    "D":
      ensure => installed;
    "R":
      ensure => purged;
    ...
    "T":
      ensure => purged;
  }
}

class bar
  package {
    "A":
      ensure => purged;
    ...
    "D":
      ensure => purged;
    "R":
      ensure => installed;
    ...
    "T":
      ensure => installed;
  }
}


Is there a better way to do this?

Cheers,
Ryan

On Tue, 31 Jul, 2007 at 19:02:09 -0700, Ryan Dooley wrote:
> Had a thought and I don''t think I see an obvious way to do this...
so for
> instance:
I''m fairly early into experimenting with puppet, and i sort of have a
solution to this, but it''s not a good one, so i''m going to
chime in in
hopes that i can get some advice too.

I like to setup every machine so that it is either explicitly a foo
server or explicitly not a foo server.  The way i''ve been doing that
is:

  node n1 {
    $foo_server = true
    $bar_server = false
    include all-services
  }

  class all-services {
    include foo-server
    include bar-server
  }

  class foo-server {
    Package {
      ensure => $foo_server ? {
        true => installed,
        false => purged,
      }
    }
    package {
      "A":
      "D":
    }
  }

And so forth.  Then, if you wanted to change n1''s definition,
you''d just
change the node def so that $foo_server = false and $bar_server = true,
and it should Just Work (in theory).

This is more elegant than anything else that immediately came to mind,
but it''s obviously not great, because it''s complicated to
maintain.
In particular, the use of variables to indicate whether a machine is
part of a class or not is kludgy and redundant, and i''ve run into
scoping
issues even in simple lab examples.  Perhaps worse, if foo-server
and bar-server had a package in common, there would be a conflict if
a machine was one but not the other, and it seems like that situation
would crop up eventually.

So, if whoever answers Ryan''s question wanted to also give me hints as
to a better way to do what i have in mind here, that would be great.

Chaos

On Aug 1, 2007, at 8:03 AM, Chaos Golubitsky wrote:
> [...]
> And so forth.  Then, if you wanted to change n1''s definition,
you''d
> just
> change the node def so that $foo_server = false and $bar_server =  
> true,
> and it should Just Work (in theory).
This is basically the only way to provide this functionality right  
now, other than (of course) rebuilding the machine from scratch when  
you change its purpose, which is, frankly, the best way to do that.
> This is more elegant than anything else that immediately came to mind,
> but it''s obviously not great, because it''s complicated to
maintain.
> In particular, the use of variables to indicate whether a machine is
> part of a class or not is kludgy and redundant, and i''ve run into
> scoping
> issues even in simple lab examples.  Perhaps worse, if foo-server
> and bar-server had a package in common, there would be a conflict if
> a machine was one but not the other, and it seems like that situation
> would crop up eventually.
There''s no good solution to this problem right now.

I''m hoping to have the development resources in the next few months  
to build the ability to do that on the client, but I have no idea if  
this will happen.

Basically, we need to start keeping track of client configuration  
state, so that we notice when a resource was previously managed and  
no longer is, and then allow users to set policy, saying things like  
no-longer-managed resources should be removed from the system.

Really, though, it''s usually not that hard rebuilding the system if  
you''re changing its purpose.

  --
  My favorite was a professor at a University I Used To Be Associated
  With who claimed that our requirement of a non-alphabetic character in
  our passwords was an abridgement of his freedom of speech.
                  -- Jacob Haller
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com