Hi,
this is my first mail to this list. I asked the following question also on stackoverflow but thought this list might be the better destination for it. The question on stackoverflow is http://stackoverflow.com/questions/17490736/chef-does-not-read-attributes-and-definitions
Anyway here it comes again:
I have a an old project I’ve built with chef (https://github.com/noha/virtual-gemstone). It uses chef together with vagrant to achieve its goal. The project was stale for the last couple of months and now I want to reactivate it. But I don’t have much luck running it with chef 11. No matter what I try the values in attributes/default.rb aren’t there. In the gemstone/attributes/default.rb file I have
default[:gemstone][:base_url] = "http://glass-downloads.gemstone.com/gss24"
default[:gemstone][:version] = "GemStone64Bit2.4.4.1-x86_64.Linux"
default[:gemstone][:dir] = "/opt/gemstone"
default[:gemstone][:log_dir] = "/opt/gemstone/log"
default[:gemstone][:lock_dir] = "/opt/gemstone/locks"
default[:gemstone][:user] = "gemstone"
default[:gemstone][:no_gems] = 3
default[:gemstone][:low_port] = 7000
default[:gemstone][:cache_path] = Chef::Config[:file_cache_path]
and in the gemstone/recipes/base.rb I have
…
tmp = node[:gemstone][:cache_path]
base_url = "#{node[:gemstone][:base_url]}"
file = "#{node[:gemstone][:version]}.zip"
dir = “#{node[:gemstone][:dir]}/#{node[:gemstone][:version]}”
…
but the values are always undefined/empty. I’ve tried even to set node.default in the attributes file and also while accessing the values in the recipe.
In order to test it I’ve copied all recipe .rb files into a single default.rb and added the content from the attributes file. This works but no it complains about a missing function that I’ve defined in gemstone/definitions/monit.rb called monit_gem.
The whole project was working months before. So I think there is something fundamentally wrong with my current setup for chef 11. But I couldn’t find much that needs to be tweaked for this in order to work properly.
I’ve run chef-solo on my linux box with debugging on and I could see that for the first recipe (the one in the run_list) it loads an attributes file but not for any of the following. Putting all desired config values in the attributes file of the first recipe makes them available in the following recipes (although this kind of setup is not wanted). And it stops at the definition problem.
Any ideas?
thanks,
Norbert
Are you using "include_recipe" to bring in your other cookbooks? If
so, you must also list the included cookbook as a dependency (in
metadata.rb of the including cookbook), or the attributes files won't
be loaded.
Cheers,
--
Nathaniel Eliot
T9 Productions
On Fri, Jul 5, 2013 at 9:45 AM, Norbert Hartl norbert@hartl.name wrote:
Hi,
this is my first mail to this list. I asked the following question also on
stackoverflow but thought this list might be the better destination for it.
The question on stackoverflow is
Chef does not read attributes and definitions - Stack Overflow
Anyway here it comes again:
I have a an old project I've built with chef
(GitHub - noha/virtual-gemstone: bootstrapping a virtual appliance that runs the GemStone OO database and prerequisites to run web applications). It uses chef together with
vagrant to achieve its goal. The project was stale for the last couple of
months and now I want to reactivate it. But I don't have much luck running
it with chef 11. No matter what I try the values in attributes/default.rb
aren't there. In the gemstone/attributes/default.rb file I have
default[:gemstone][:base_url] =
"http://glass-downloads.gemstone.com/gss24"
default[:gemstone][:version] = "GemStone64Bit2.4.4.1-x86_64.Linux"
default[:gemstone][:dir] = "/opt/gemstone"
default[:gemstone][:log_dir] = "/opt/gemstone/log"
default[:gemstone][:lock_dir] = "/opt/gemstone/locks"
default[:gemstone][:user] = "gemstone"
default[:gemstone][:no_gems] = 3
default[:gemstone][:low_port] = 7000
default[:gemstone][:cache_path] = Chef::Config[:file_cache_path]
and in the gemstone/recipes/base.rb I have
...
tmp = node[:gemstone][:cache_path]
base_url = "#{node[:gemstone][:base_url]}"
file = "#{node[:gemstone][:version]}.zip"
dir = "#{node[:gemstone][:dir]}/#{node[:gemstone][:version]}"
...
but the values are always undefined/empty. I've tried even to set
node.default in the attributes file and also while accessing the values in
the recipe.
In order to test it I've copied all recipe .rb files into a single
default.rb and added the content from the attributes file. This works but no
it complains about a missing function that I've defined in
gemstone/definitions/monit.rb called monit_gem.
The whole project was working months before. So I think there is something
fundamentally wrong with my current setup for chef 11. But I couldn't find
much that needs to be tweaked for this in order to work properly.
I've run chef-solo on my linux box with debugging on and I could see that
for the first recipe (the one in the run_list) it loads an attributes file
but not for any of the following. Putting all desired config values in the
attributes file of the first recipe makes them available in the following
recipes (although this kind of setup is not wanted). And it stops at the
definition problem.
Any ideas?
thanks,
Norbert
Am 05.07.2013 um 17:02 schrieb Nathaniel Eliot temujin9@t9productions.com:
Are you using "include_recipe" to bring in your other cookbooks? If
so, you must also list the included cookbook as a dependency (in
metadata.rb of the including cookbook), or the attributes files won't
be loaded.
That did the trick. Thank you very much. I thought I had the metadata correct but…
Norbert
Cheers,
--
Nathaniel Eliot
T9 Productions
On Fri, Jul 5, 2013 at 9:45 AM, Norbert Hartl norbert@hartl.name wrote:
Hi,
this is my first mail to this list. I asked the following question also on
stackoverflow but thought this list might be the better destination for it.
The question on stackoverflow is
Chef does not read attributes and definitions - Stack Overflow
Anyway here it comes again:
I have a an old project I've built with chef
(GitHub - noha/virtual-gemstone: bootstrapping a virtual appliance that runs the GemStone OO database and prerequisites to run web applications). It uses chef together with
vagrant to achieve its goal. The project was stale for the last couple of
months and now I want to reactivate it. But I don't have much luck running
it with chef 11. No matter what I try the values in attributes/default.rb
aren't there. In the gemstone/attributes/default.rb file I have
default[:gemstone][:base_url] =
"http://glass-downloads.gemstone.com/gss24"
default[:gemstone][:version] = "GemStone64Bit2.4.4.1-x86_64.Linux"
default[:gemstone][:dir] = "/opt/gemstone"
default[:gemstone][:log_dir] = "/opt/gemstone/log"
default[:gemstone][:lock_dir] = "/opt/gemstone/locks"
default[:gemstone][:user] = "gemstone"
default[:gemstone][:no_gems] = 3
default[:gemstone][:low_port] = 7000
default[:gemstone][:cache_path] = Chef::Config[:file_cache_path]
and in the gemstone/recipes/base.rb I have
...
tmp = node[:gemstone][:cache_path]
base_url = "#{node[:gemstone][:base_url]}"
file = "#{node[:gemstone][:version]}.zip"
dir = "#{node[:gemstone][:dir]}/#{node[:gemstone][:version]}"
...
but the values are always undefined/empty. I've tried even to set
node.default in the attributes file and also while accessing the values in
the recipe.
In order to test it I've copied all recipe .rb files into a single
default.rb and added the content from the attributes file. This works but no
it complains about a missing function that I've defined in
gemstone/definitions/monit.rb called monit_gem.
The whole project was working months before. So I think there is something
fundamentally wrong with my current setup for chef 11. But I couldn't find
much that needs to be tweaked for this in order to work properly.
I've run chef-solo on my linux box with debugging on and I could see that
for the first recipe (the one in the run_list) it loads an attributes file
but not for any of the following. Putting all desired config values in the
attributes file of the first recipe makes them available in the following
recipes (although this kind of setup is not wanted). And it stops at the
definition problem.
Any ideas?
thanks,
Norbert