[Puppet Users] Re: Creating classes for individual nodes
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.orgwrote: 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.
Re: [Puppet Users] Re: Creating classes for individual nodes
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.orgwrote: 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.
[Puppet Users] Re: Creating classes for individual nodes
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.