Creating classes for individual nodes

[Josh]

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

[Dan White]

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)

> --
> 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...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

[jcbollinger]

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

[Brian Gallew]

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.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

[Josh]

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