Thanks. I made a library instance method to access these attributes
dynamically. This solves the code duplication issue.
However, I’m still unaware of a good way to ‘set’ these variables
automatically via a library so that they become available to all recipes
within the Chef run. Ideally the variables become available to all
cookbooks that have ‘depend “helper-cookbook”’ in metadata.rb, and
redundant calls to the Chef API are eliminated. Is this even possible?
How it exists currently:
return env, server
env, server = my_helper_module
Any tips or suggestions?
On Tue, Apr 28, 2015 at 5:21 PM, Tensibai Zhaoying email@example.com
I don’t know if it’s the best way but we so this with an Env cookbook with
many attributes files, one common for all invariable values and one file
per Env starting With 'return unless node.chef_environment == “target_env”'
Le 28 avr. 2015 19:28, Mathew Crane firstname.lastname@example.org a écrit :
- Two custom variables are dynamically assigned based on
node.chef_environment via a targeted search and subsequent for-loop against
a max of 10 top-level data bag items.
- Both variables are a DataBagItem.
- They are defined within any recipe that needs these values.
- Setting this in every recipe doesn’t scale.
Is there a way to define these variables once in a separate,
single-purpose cookbook recipe, and have them reliably made available to
all recipes within the chef run?
What is the best direction for this? Setting attributes via
attributes/default.rb or creating a custom library with a ruby block?