-
-
Save jnwng/5317609 to your computer and use it in GitHub Desktop.
| if default['postgresql']['version'] == "9.1" | |
| default['postgresql']['main_dir'] = "foo" | |
| else | |
| default['postgresql']['main_dir'] = "bar" |
| normal['postgresql']['version'] = "9.1" |
| default['postgresql']['version'] = "9.2" | |
| default['postgresql']['dir'] = "/etc/postgresql/#{node['postgresql']['version']}/main" |
I could be very wrong if the default['postgresql']['dir'] attribute doesn't get actually evaluated until use, however based on the last couple of days that I've dealt with this, it looks like the attributes that depend on this being here don't get updated (which makes sense given how its coded). Roles would work, as well as environments, but previously, before Chef 11, it worked pretty well to just override inside this cookbook.
It is also the case that if the second attribute is nested inside of an attribute test, that it would remain out-of-date when it gets evaluated (see third Gist).
Not particularly sure what the best method is of overriding these attributes, but presumably its too much to ask to understand what node attribute depend on other attributes. However, might be the case that people need to document these attribute dependencies, or otherwise specify these attributes in environments as opposed to in their cookbooks (although cookbooks make the most sense).
Some context, using chef-solo and chef 11. Just trying to hopefully clarify some of the attribute changes that were made
Imagine the situation as such:
my_cookbookhas a dependency onpostgresqlcookbook. I override thepostgresqlcookbook version with 9.1, and only that attribute. However,my_cookbookdepends onpostgresqlcookbook, meaning it gets loaded before my cookbook (via Chef 11). Therefore,postgresqlattributes get evaluated before mine, and although I have a better attribute precedence via normal, the secondpostgresqlattribute depends on the first, and is now out of date whenmy_cookbookattributes are evaluated for the node.