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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
