Puppet users - Apr 2012 - Creating classes for individual nodes

This is more of a style question than implementation. I have a bunch of 
nodes running the same software but in many cases they need config files 
that are customized for that specific node. I was thinking I could push all 
the main files from the app through a central class and have separate 
classes for each individual node that has the config files. Is this the 
best way to do this or does it go against the purpose of using puppet?

Also, for implementation, is it best practice to create a separate module 
and class for each node where the class includes only that module? Thanks.

Josh

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/nfC30zTpr1oJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

My only objection is that mixes up the configuration data with the Puppet code,
making things less modular/portable.

I have set up a collection of parameterized classes such that all the
server-unique info is in /etc/puppet/manifests/nodes/ in various
<whatever>-node.pp files.

I hope to transition to hiera to further separate the configuration data and
Puppet code.

http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/

“Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

----- Josh <joshua.l.greenberg@gmail.com> wrote:
> This is more of a style question than implementation. I have a bunch of 
> nodes running the same software but in many cases they need config files 
> that are customized for that specific node. I was thinking I could push all
> the main files from the app through a central class and have separate 
> classes for each individual node that has the config files. Is this the 
> best way to do this or does it go against the purpose of using puppet?
> 
> Also, for implementation, is it best practice to create a separate module 
> and class for each node where the class includes only that module? Thanks.
> 
> Josh
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/nfC30zTpr1oJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Apr 11, 12:04 pm, Josh <joshua.l.greenb...@gmail.com>
wrote:
> This is more of a style question than implementation. I have a bunch of
> nodes running the same software but in many cases they need config files
> that are customized for that specific node. I was thinking I could push all
> the main files from the app through a central class and have separate
> classes for each individual node that has the config files. Is this the
> best way to do this or does it go against the purpose of using puppet?

There is no inherent problem with that approach, but for a little
extra effort you can get something that will be easier to maintain.
I''m not a big fan of parameterized classes myself, but I heartily
endorse an external data store, accessed via Hiera.  Instead of using
per-node classes, record per-node data where needed.  You can use that
data to fill templates, choose among alternatives in your manifests,
set resource properties, etc..

> Also, for implementation, is it best practice to create a separate module
> and class for each node where the class includes only that module? Thanks.

I would say not.  It might or might not make sense to put the per-node
classes in the module with the main classes for the application in
question, but I certainly see no reason to separate them from each
other.  But the question is moot if you choose a cleaner strategy.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I''m absolutely with John on this.  As an example, for our JBoss
application
we need the configuration file to be different based on the the hostname
(we only host one app per host/VM) and environment
(dev/integration/qa/staging/production).  Further, some "dev" boxes
need to
allow the developers to hand-update their configs.  So what I have is a
templated configuration file that has all the configuration information in
it for all the environments, and only the pertinent information gets
shipped to the Puppet client.  Further, I wrap this in a define{} so that
the file Puppet actually manages is "server.properties-default". 
There is
an exec{} in the define which checks for a
"server.properties-noupdate"
file.  If that file exists, the exec{} bails.  If it doesn''t, then it
rsync''s the -default file onto the "server.properties" file
that JBoss
references.  Finally, the define{} also creates a
"server.properties-README" which tells the developer about how the
file is
managed and what they can do if they want to override Puppet.


On Wed, Apr 11, 2012 at 1:52 PM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
>
> On Apr 11, 12:04 pm, Josh <joshua.l.greenb...@gmail.com> wrote:
> > This is more of a style question than implementation. I have a bunch
of
> > nodes running the same software but in many cases they need config
files
> > that are customized for that specific node. I was thinking I could
push
> all
> > the main files from the app through a central class and have separate
> > classes for each individual node that has the config files. Is this
the
> > best way to do this or does it go against the purpose of using puppet?
>
>
> There is no inherent problem with that approach, but for a little
> extra effort you can get something that will be easier to maintain.
> I''m not a big fan of parameterized classes myself, but I heartily
> endorse an external data store, accessed via Hiera.  Instead of using
> per-node classes, record per-node data where needed.  You can use that
> data to fill templates, choose among alternatives in your manifests,
> set resource properties, etc..
>
>
> > Also, for implementation, is it best practice to create a separate
module
> > and class for each node where the class includes only that module?
> Thanks.
>
>
> I would say not.  It might or might not make sense to put the per-node
> classes in the module with the main classes for the application in
> question, but I certainly see no reason to separate them from each
> other.  But the question is moot if you choose a cleaner strategy.
>
>
> John
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks everyone! This is a good start. I''ll have to research most of
this but at least I know what to research now. Thanks.

Josh

On Apr 12, 10:19 am, Brian Gallew <g...@gallew.org>
wrote:
> I''m absolutely with John on this.  As an example, for our JBoss
application
> we need the configuration file to be different based on the the hostname
> (we only host one app per host/VM) and environment
> (dev/integration/qa/staging/production).  Further, some "dev"
boxes need to
> allow the developers to hand-update their configs.  So what I have is a
> templated configuration file that has all the configuration information in
> it for all the environments, and only the pertinent information gets
> shipped to the Puppet client.  Further, I wrap this in a define{} so that
> the file Puppet actually manages is "server.properties-default".
 There is
> an exec{} in the define which checks for a
"server.properties-noupdate"
> file.  If that file exists, the exec{} bails.  If it doesn''t, then
it
> rsync''s the -default file onto the "server.properties"
file that JBoss
> references.  Finally, the define{} also creates a
> "server.properties-README" which tells the developer about how
the file is
> managed and what they can do if they want to override Puppet.
>
> On Wed, Apr 11, 2012 at 1:52 PM, jcbollinger
<John.Bollin...@stjude.org>wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 11, 12:04 pm, Josh <joshua.l.greenb...@gmail.com> wrote:
> > > This is more of a style question than implementation. I have a
bunch of
> > > nodes running the same software but in many cases they need
config files
> > > that are customized for that specific node. I was thinking I
could push
> > all
> > > the main files from the app through a central class and have
separate
> > > classes for each individual node that has the config files. Is
this the
> > > best way to do this or does it go against the purpose of using
puppet?
>
> > There is no inherent problem with that approach, but for a little
> > extra effort you can get something that will be easier to maintain.
> > I''m not a big fan of parameterized classes myself, but I
heartily
> > endorse an external data store, accessed via Hiera.  Instead of using
> > per-node classes, record per-node data where needed.  You can use that
> > data to fill templates, choose among alternatives in your manifests,
> > set resource properties, etc..
>
> > > Also, for implementation, is it best practice to create a
separate module
> > > and class for each node where the class includes only that
module?
> > Thanks.
>
> > I would say not.  It might or might not make sense to put the per-node
> > classes in the module with the main classes for the application in
> > question, but I certainly see no reason to separate them from each
> > other.  But the question is moot if you choose a cleaner strategy.
>
> > John
>
> > --
> > You received this message because you are subscribed to the Google
Groups
> > "Puppet Users" group.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > puppet-users+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/puppet-users?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.