We're currently putting location specific attributes into roles. We have one role per location (multiple Amazon regions, us1, us2 etc). Examples of this location specific data might include things like the redis server, the apt-cache server address, amazon bucket names to use for various things and so on.
With our current approach, for any given node, the run list typically contains 1) the location role, 2) the base role added by our provisioning script, and 3) a role that defines what the node does, like this:
{
...
"run_list": [
"role[role_base]",
"role[role_downloader_app]",
"role[location_us1_prod]"
]
}
And, the functional role, role_downloader_app, would contain the actual recipe that does the work, e.g.:
// role_downloader_app.
// A role for a download server.
{
"name": "role_downloader_app",
...
"run_list": [
"recipe[bc-foo-downloader::dl]"
],
}
By not adding the base role until the node is provisioned on ec2, it allows for quicker testing with vagrant.
So, getting to the point…
If I take the location specific attributes and put it into a cookbook instead of a role, it's going to become very messy. With a role, only the specific data for that role is added to the name space. If I use a cookbook, I have to put everything into the default/attributes file and qualify it for the location. Eg:
default['us1'] = { … }
default['eu2'] = { … }
and so on. Then, to actually _use_ the attribute in a cookbook I have to qualify it again. Instead of saying node['some_sever], I have to say node['us1']['some_server']. This is cumbersome. I could create one recipe per location, only include that recipe and then set the attributes in the recipe, but it seems like this may not be the best approach either.
There's plenty of blogs out there on putting roles into cookbooks but they all seem to gloss over the details and not go beyond generally saying don't put role data in roles.
Thanks,
Doug.