I was just curious why you gave the ability to provide multiple versions of the
same file or template for different OS’s (File Specificity), but not for
recipes.
On Tue, Dec 6, 2011 at 11:20 PM, bjbq4d@gmail.com wrote:
I was just curious why you gave the ability to provide multiple versions of the
same file or template for different OS's (File Specificity), but not for
recipes.
Speaking as just a user, I can think of only a handful of cookbooks
where I would want to completely override a recipe depending on the
OS: in most cases it's just a few resources that need to be
OS-specific, the rest of the recipe is cross-platform.
Moreover, in the case of templates, the file is (mostly) the same
across platform; it's just the content that changes, so that's easy.
Compare that to packages, where you have almost as many variations as
the number of existing distros 
That said, in some case things diverge so much between distros that it
may make sense; in those cases it's quite trivial to roll your own.
See https://github.com/opscode/cookbooks/tree/master/postgresql/recipes
for an example of how easy it can be.
Andrea
On Tue, Dec 6, 2011 at 5:20 PM, bjbq4d@gmail.com wrote:
I was just curious why you gave the ability to provide multiple versions of the
same file or template for different OS's (File Specificity), but not for
recipes.
To build on what Andrea Camp said, a good practice is to keep as much
logic out of templates as possible and put it in recipes. If you're
installing from upstream packages, you're likely going to have a
different configuration file for each distribution and release because
they have different versions of the package. In this case you can copy
the default configuration files in and use file specificity to choose
which to use. Then you edit the templates where you need to fill in
values and provide those values using the same variable names in the
template resource in the recipe. If you're filling in a field this way
and the source of the field changes, you only have to change that once
in the recipe rather than in every template. The templates are much
easier to read and work with this was as well.
The recipes really shouldn't differ significantly between different
OS's. This is the goal of abstracting away the tedious bits with
resources like package. If the package name happens to be different,
the package resource doesn't need to be changed except for that one
value.
mysql_service_name = value_for_platform([ "centos", "redhat", "suse",
"fedora", "scientific" ] => {"default" => "mysqld"}, "default" =>
"mysql")
some_package = value_for_platform(
["centos", "redhat", "suse", "fedora", "scientific" ] =>
{"default" => "something_red"},
["ubuntu", "debian"] => { "11.10" => "something_special",
"default" => "something_canonical" }
)
package "cool thing" do
package_name some_package
action :install
end
template "/etc/some/config" do
owner "root"
group "root"
source "config.erb"
mode "0644"
end
This way you don't need to maintain duplicate copies of the recipe for
each operating system. If you need to do something else in this
recipe, you don't need to add those resources to multiple recipes to
have it affect all systems.
Bryan
I would guess that it's due to the fact that recipes are designed with "if OS" logic where templates are designed to be logic free?
On Dec 6, 2011, at 2:20 PM, bjbq4d@gmail.com wrote:
I was just curious why you gave the ability to provide multiple versions of the
same file or template for different OS's (File Specificity), but not for
recipes.
"Designed" - no. "A good idea" - yes.
In other words, treat templates like "views" in a model/view/controller framework.
On Dec 6, 2011, at 16:12, Joshua Miller jassinpain@gmail.com wrote:
I would guess that it's due to the fact that recipes are designed with "if OS" logic where templates are designed to be logic free?
On Dec 6, 2011, at 2:20 PM, bjbq4d@gmail.com wrote:
I was just curious why you gave the ability to provide multiple versions of the
same file or template for different OS's (File Specificity), but not for
recipes.