I’ve spent the past couple hours trying to figure out an issue I’ve been having
with with ohai plugins and the ohai_plugin recipe of nginx. I’m running Chef
11.14.6, using the nginx 2.7.4 cookbook, and am experiencing the issue below
when running either chef-solo in Vagrant or chef-client on a Rackspace cloud
server, running Centos 5.10 in both environments.
What’s happening is that, the first time that I do a Chef run, I consistently
get a Ohai::Exceptions::AttributeNotFound error with the text of “No such
attribute: ‘nginx’”, referring to line 22 of the ohai_plugin nginx recipe,
which is an ohai resource hook for reloading the nginx plugin in response to a
notification by the template resource that creates the plugin a few lines down.
After this failure, if I perform another Chef run, the provisioning completes
successfully.
As far as I can tell, this is caused by a custom cookbook named “timezone” that
is included in an application cookbook before the nginx default recipe that
ensures that some custom ohai plugins that we use are available. In this
timezone cookbook, I have a files/default/plugins directory containing ohai
plugins, and, in the cookbook’s default attributes file, I have a
"default[‘ohai’][‘plugins’][‘timezone’] = ‘plugins’", paired with an
"include_recipe ‘ohai’" line in the cookbook’s default recipe. Run on its own,
this cookbook properly installs the ohai plugins contained in its files
directory at compile time, which are then picked up in the ohai refresh that
follows. However, when run in conjunction with the nginx::ohai_plugin recipe,
which includes the ohai cookbook’s default recipe, I run into the
AttributeNotFound error.
I think that I’m missing something fundamental with ohai plugin distribution,
but it seems like this error is due to ohai installing the plugins specified by
the node[‘ohai’][‘plugins’] attribute at compile time, which is then followed
by the template for the nginx ohai plugin being generated at execution time,
which is in turn followed by the ‘ohai’ recipe being included again, which is
not re-running the compile-time evaluation of ohai plugins, which is causing
the nginx plugin to not be seen during the initial Chef run. Since the file is
created before the ohai resource tries to reload the ‘nginx’ plugin, the second
Chef client run already sees this file, and is able to reload Ohai
successfully.
The question from all of this is, am I missing something about distributing
Ohai plugins in a way that doesn’t depend on other cookbooks to not include the
ohai cookbook’s default recipe? Is something about the way that I’m
distributing Ohai plugins unorthodox? Am I setting attributes or including
recipes at the wrong time in the wrong place? Any ideas?