In Chef 10 I have a number of roles which set custom node attributes like
"appname": "my_rails_app"
The attribute is then used to load app specific variables in a wrapper cookbook. There are different variables and number of variables for each Rails app for example.
app = Chef::EncryptedDataBagItem.load('deploy', node.appname)
In Chef 11 my run fails because 'node.appname' isn't set until after a successful Chef run. This means server creation has become a 2 step process - launch with base role then bootstrap wrapper cookbook.
I understand why this behavior was changed but I'm curious how to work around it without rewriting my cookbooks and still adhere to DRY.
UPDATE
Thanks this is interesting but I'm not sure this works. For example, the generic deploy cookbook which also depends on appname is included in the my_rails_app recipe. So a run looks like
Role - where attribute is set
"appname": "my_rails_app"
App wrapper cookbook - load variables
include_recipe "deploy"
app = Chef::EncryptedDataBagItem.load('deploy', node.appname)
Deploy cookbook - load SSH keys
app = Chef::EncryptedDataBagItem.load('deploy', node.appname)
The deploy cookbook is what kills the Chef run.
Default attributes already defined in a cookbooks attribute files can be resolved again during a chef client run with
node.from_file
:This is a section yanked from my answers about using attributes:
If you are doing this, you may need to think about saving the node back to the server if this is an important enough checkpoint in your process to warrant extra calls back to the chef server.