So, if you are working with a cookbook, you may get to the point, where your default attributes file starts to look like an utter mess. As you add more options or configuration parameters, it gets harder and harder to sort what is going on in your attributes file. This is one of the reasons applications like nginx and apache allow for includes. In the same fashion, you can add additional attributes files, but by default you do not have access to them unless you include them in part of your recipes.
Ok, so let me take a step back and explain a couple of the reasons that you may want to separate out the attributes that you have in the default attributes file. For a large number of cookbooks, maintaining a single attributes file makes a lot of sense. However, there are situations where using multiple attributes files is an asset.
- You have a large number of variables that need to be set
- Some attributes are only needed under certain conditions
- Passing values based upon an environment
After working on this for the past couple of days, it has become obviously clear, that the docs are a bit messed up. ANY FILE that is in the attributes file will be read. This makes it extremely easy to pull in values to be used. However, it does make it a bit more problematic for setting values based upon environments. That is really a small price to pay.
Instead of talking about how to pull them in, I am going to talk instead about breaking up attributes into files that make sense. This is extremely important. If you have ever had to parse through a 2000 line config file to find a setting, they you might understand my pain. So, if you have a cookbook that does a multitude of things, break the attributes up into small workable parts.
I am done, because there is nothing more to say, other than that Chef docs can make a person want to pull out his hair.