Abstract
File Specificity is a feature of Chef where a Cookbook file or template is dynamically sourced based on the hostname and platform of the system under management. The current implementation of file specificity has the following disadvantages:
- Users who do not need this feature are required to understand or at least be aware of it in order to create cookbooks: The directory layouts for templates and cookbook files counterintuitively require the user to place files under a default/ directory. Before learning about file specificity, users expect to be able to place cookbook files and templates in the root of the files/ and templates/ directories, respectively.
- There is no way for specificity to operate on any property other than hostname and platform: Many users have homogenous (or reasonably homogenous) environments, but would have a use for specificity based on geography (datacenter A gets a different file), environment (production/qa/dev gets a different file) or another property.
To resolve these deficiencies, file specificity should be opt-in and explicit. When no specificity is declared, files should be fetched from the root of files/ or templates/ as appropriate. When enabled, file specificity should support user-defined specificity rules on a per-resource basis.
Compatibility Concerns
If implemented immediately with no deprecation period, this proposal would break almost every cookbook. Therefore, if implemented, it must be implemented in stages across several major releases of Chef, with backwards compatibility maintained for a reasonable amount of time and clear messaging to users about what is changing, when, and why. If possible, automated tooling should be provided to migrate cookbooks.
Implementation.
Source as Array
The fully explicit syntax would look like this:
However, helper methods can be provided to make this less onerous:
Explicit Specificity Option
TODO
Adds a specificity attribute, which takes a code block or a symbol...