Created
November 4, 2010 20:25
-
-
Save lusis/663131 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
############################################################## | |
## In a given puppet module, you might have something like: ## | |
##class foo { ## | |
## $fragments = ["property1", "property2"] ## | |
## ## | |
## file { ## | |
## "/etc/myapp/myapp.config": ## | |
## ensure => present, ## | |
## content => template("template.erb"); ## | |
## } ## | |
############################################################## | |
# This is a module specific setting | |
module_specific_setting = 0 | |
# included from shared setting - property1 | |
some_shared_setting = 1 | |
# included from shared setting - property2 | |
some_other_shared_setting=foobarbaz | |
logdir=/var/log/myapp |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# included from shared setting - property1 | |
some_shared_setting = 1 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# included from shared setting - property2 | |
some_other_shared_setting=foobarbaz | |
logdir=/var/log/myapp |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
############################################################## | |
## In a given puppet module, you might have something like: ## | |
##class foo { ## | |
## $fragments = ["property1", "property2"] ## | |
## ## | |
## file { ## | |
## "/etc/myapp/myapp.config": ## | |
## ensure => present, ## | |
## content => template("template.erb"); ## | |
## } ## | |
############################################################## | |
# This is a module specific setting | |
module_specific_setting = 0 | |
<% fragments.each do |fragment| -%> | |
<%= scope.function_template("fragments/#{fragment}.erb") %> | |
<% end -%> |
How does this differ from using template to concatenate ERB files in the language? Does this pattern allow us to easily "override" parameters, or would you use something like extlookup() for that?
e.g.
$fragments = ["header.erb", "fragments/property1", "fragments/property2", "footer.erb" ]
file {
"/etc/myapp/myapp.config":
ensure => present,
content => template($fragments);
}
Well we use cobbler for external node data so that might have been the reason. I'm trying to remember where the headache was but every trick I tried didn't work. The fragments actually map to managment classes in cobbler and have their own set of variables that come from site.pp (bad place, I know).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The reasoning for this:
Imagine you have multiple in-house applications that share attributes but also have unique settings for themselves. You COULD use a single configfile with multiple nested conditionals but that gets unweildy very quickly. It's risky to manage as well. What is instead of looping over a set of "property attributes" ($fragments), and including based on "if property1, include X", you can generate a final configuration file before shipping it over to a remote host. Sort of a "conditional concat" to generate a final file from an ERB template.
All puppet variables in a module are accessible to the fragments which is where this really shines.