Puppet users - Sep 2006 - Recommendations for organizing hosts into groups?

I have a few different groupings of hosts, and I am wondering what is  
the best way to organize the node configuration for them.

I have a few machines that are VMware hosts, a bunch of VMware  
guests, and the main admin server which runs a bunch of stuff like  
puppetmasterd.

I''ve got a bunch of classes/*.pp which define configuration for sudo,  
yum, java, etc.  Right now I just have them all using
''default'':

<snip>
node default {
     include sudo
     include motd
     include dns
     include yum
     include java
}
</snip>

Most of the hosts will need this default set of classes, and then  
each group will have a super set.

Any tips on how to best organize them?

Thanks,

--jason

On Tue, 2006-09-19 at 05:15 -0700, Jason Dillon wrote:
> I have a few different groupings of hosts, and I am wondering what is  
> the best way to organize the node configuration for them.
> 
> I have a few machines that are VMware hosts, a bunch of VMware  
> guests, and the main admin server which runs a bunch of stuff like  
> puppetmasterd.
> 
> I''ve got a bunch of classes/*.pp which define configuration for
sudo,
> yum, java, etc.  Right now I just have them all using
''default'':
> 
> <snip>
> node default {
>      include sudo
>      include motd
>      include dns
>      include yum
>      include java
> }
> </snip>
> 
> Most of the hosts will need this default set of classes, and then  
> each group will have a super set.
I would be inclined to model this using inheritance, either of classes
or of nodes; which one is more suitable depends a little on how
different individual machines are. If they cleanly fall into a number of
categories, I would define a ''class any-host'', just like your
default
node above and then subclass that for VMWare guests, hosts and the admin
server, though the latter probably doesn''t warrant it''s own
class.

The goal of all that should be to describe the configuration of your
whole site with as little duplication (in the form of cut-and-paste) as
possible.

David

Okay, I think this is starting to sink in... is this what you are  
talking about:

<snip>
# Basic node config for any host
class any-host {
     include sudo
     include motd
     include dns
     include yum
     include java
}

# Config for VMware servers
class vmware-server inherits any-host {
     include vmware-server
}

# Config for VMware servers
class other-server inherits any-host {
     include other-server
}

# Any nodes not matched below
node default {
     include any-host
}

# A VMware server
node ''vmware1.host'' {
     include vmware-server
}

# Another VMware server
node ''vmware2.host'' {
     include vmware-server
}

# Some other host with other config
node ''other1.host'' {
     include other-server
}

# Some other host with other config
node ''other2.host'' {
     include other-server
}

# Special host only gets this config, nothing imported
node ''special.host'' {
     templatefile { "/etc/motd":
         mode => 444,
         source => "system/specialmotd.erb"
     }
}
</snip>

I am still a bit fuzzy on how node inheritance works... have not seen  
any examples of that.

--jason



On Sep 19, 2006, at 6:25 AM, David Lutterkort wrote:
> On Tue, 2006-09-19 at 05:15 -0700, Jason Dillon wrote:
>> I have a few different groupings of hosts, and I am wondering what is
>> the best way to organize the node configuration for them.
>>
>> I have a few machines that are VMware hosts, a bunch of VMware
>> guests, and the main admin server which runs a bunch of stuff like
>> puppetmasterd.
>>
>> I''ve got a bunch of classes/*.pp which define configuration
for sudo,
>> yum, java, etc.  Right now I just have them all using
''default'':
>>
>> <snip>
>> node default {
>>      include sudo
>>      include motd
>>      include dns
>>      include yum
>>      include java
>> }
>> </snip>
>>
>> Most of the hosts will need this default set of classes, and then
>> each group will have a super set.
>
> I would be inclined to model this using inheritance, either of classes
> or of nodes; which one is more suitable depends a little on how
> different individual machines are. If they cleanly fall into a  
> number of
> categories, I would define a ''class any-host'', just like
your default
> node above and then subclass that for VMWare guests, hosts and the  
> admin
> server, though the latter probably doesn''t warrant it''s
own class.
>
> The goal of all that should be to describe the configuration of your
> whole site with as little duplication (in the form of cut-and- 
> paste) as
> possible.
>
> David
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users

Jason Dillon wrote:
> Okay, I think this is starting to sink in... is this what you are  
> talking about:
This is basically right except... (comments below)
> <snip>
> # Basic node config for any host
> class any-host {
>      include sudo
>      include motd
>      include dns
>      include yum
>      include java
> }
> 
> # Config for VMware servers
> class vmware-server inherits any-host {
>      include vmware-server
> }
> 
> # Config for VMware servers
> class other-server inherits any-host {
>      include other-server
> }
For these two classes, you''d want to actually have code; you
can''t
include the class that you''re in, so this would be an error. 
You''d
instead include service classes, manage vmware, or whatever.
> # Any nodes not matched below
> node default {
>      include any-host
> }
> 
> # A VMware server
> node ''vmware1.host'' {
>      include vmware-server
> }
> 
> # Another VMware server
> node ''vmware2.host'' {
>      include vmware-server
> }
> 
> # Some other host with other config
> node ''other1.host'' {
>      include other-server
> }
> 
> # Some other host with other config
> node ''other2.host'' {
>      include other-server
> }
> 
> # Special host only gets this config, nothing imported
> node ''special.host'' {
>      templatefile { "/etc/motd":
>          mode => 444,
>          source => "system/specialmotd.erb"
>      }
> }
> </snip>
Yep, this all looks about how I do things.
> I am still a bit fuzzy on how node inheritance works... have not seen  
> any examples of that.
Node inheritance isn''t currently any different than specifically 
including a class in a node''s definition.  I expect the parser work
I''m
doing right now to result in node inheritance being similar to class 
inheritance, such that a node could override code in the basenode.

-- 
A conservative is a man who believes that nothing should be done for
the first time.        --Alfred E. Wiggam
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

On Sep 19, 2006, at 2:21 PM, Luke Kanies wrote:
>> # Config for VMware servers
>> class vmware-server inherits any-host {
>>      include vmware-server
>> }
>>
>> # Config for VMware servers
>> class other-server inherits any-host {
>>      include other-server
>> }
>
> For these two classes, you''d want to actually have code; you
can''t
> include the class that you''re in, so this would be an error. 
You''d
> instead include service classes, manage vmware, or whatever.
Oh... too bad.  I guess I can create components to abstract the code  
instead of using classes.

>> I am still a bit fuzzy on how node inheritance works... have not seen
>> any examples of that.
>
> Node inheritance isn''t currently any different than specifically
> including a class in a node''s definition.  I expect the parser
work
> I''m
> doing right now to result in node inheritance being similar to class
> inheritance, such that a node could override code in the basenode.
Is there a situation where you would recommend using node inheritance  
over class inheritance?

--jason

Jason Dillon wrote:
> On Sep 19, 2006, at 2:21 PM, Luke Kanies wrote:
>> For these two classes, you''d want to actually have code; you
can''t
>> include the class that you''re in, so this would be an error. 
You''d
>> instead include service classes, manage vmware, or whatever.
> 
> Oh... too bad.  I guess I can create components to abstract the code  
> instead of using classes.
After chatting in IRC, I realize you meant ''node vmwarenode { include 
vmware-class }''.

You can do that, but note that node and class names collide, so you need 
to provide different names to them.
> Is there a situation where you would recommend using node inheritance  
> over class inheritance?
Not technically, no; there are just some times where it seems more 
appropriate.

Node inheritance is relatively recent, and was added at the request of 
other users.  At this point, node inheritance is less functional than 
class inheritance, but eventually they''ll be equivalently functional
and
it will just be up to you which you prefer.

-- 
oH for Pete''s sake, use a real filter. ;-)
                 -- Tom Christiansen
Look, I refuse to install any filter which looks like it''s more highly
evolved than homo sapiens, it will just get embarassing when it starts
critiquing the literrary style of my friends mail to me.
                 -- Richard Caley, in comp.lang.perl.misc
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com