[SOLVED] The Compiler Errors on cookbook_collection templates

Using this technique Trying to iterate through template files using this technique where centos7 is a guest of a docker container.

AND UGH!, I'M GETTING A COMPILE ERROR

==> thunt-centOS7: Recipe Compile Error in /var/chef/cache/cookbooks/proof/recipes/default.rb
==> thunt-centOS7: ================================================================================
==> thunt-centOS7:
==> thunt-centOS7: NoMethodError
==> thunt-centOS7: -------------
==> thunt-centOS7: undefined method each' for nil:NilClass ==> thunt-centOS7: ==> thunt-centOS7: Cookbook Trace: ==> thunt-centOS7: --------------- ==> thunt-centOS7: /var/chef/cache/cookbooks/proof/recipes/default.rb:17:in from_file'
==> thunt-centOS7:
==> thunt-centOS7: Relevant File Content:
==> thunt-centOS7: ----------------------
==> thunt-centOS7: /var/chef/cache/cookbooks/proof/recipes/default.rb:
==> thunt-centOS7:
==> thunt-centOS7: 10: Chef::Log.info("COOKBOOK_collection = #{run_context.cookbook_collection[cookbook_name]}")
==> thunt-centOS7: 11: Chef::Log.info("***************************************************************")
==> thunt-centOS7:
==> thunt-centOS7: 12: # Get the Chef::CookbookVersion for the current cookbook
==> thunt-centOS7:
==> thunt-centOS7: 13: cb = run_context.cookbook_collection[cookbook_name]
==> thunt-centOS7: 14: #
==> thunt-centOS7: 15: # # Loop over the array of files.
==> thunt-centOS7:
==> thunt-centOS7: 16: # # 'templates' will also work.
==> thunt-centOS7:
==> thunt-centOS7: 17>> cb.manifest['templates'].each do |tmpl_file|
==> thunt-centOS7: 18: Chef::Log("found: " + tmpl_file['name'])
==> thunt-centOS7: 19: Chef::Log.info("path: #{tmpl_file['path']}")
==> thunt-centOS7:
==> thunt-centOS7: 20: end

What am I doing wrong?

==> thunt-centOS7: System Info:
==> thunt-centOS7: ------------
==> thunt-centOS7: chef_version=13.7.16
==> thunt-centOS7: platform=centos
==> thunt-centOS7:
==> thunt-centOS7: platform_version=7.4.1708
==> thunt-centOS7:
==> thunt-centOS7: ruby=ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-linux]
==> thunt-centOS7: program_name=chef-client worker: ppid=3918;start=19:26:01;
==> thunt-centOS7:
==> thunt-centOS7: executable=/opt/chef/bin/chef-client

The templates directory looks like this...
templates
templates/default
templates/default/message.erb
templates/default/default
templates/default/default/d3
templates/default/default/d3/161
templates/default/default/d3/161/scripts
templates/default/default/d3/161/scripts/d3.profile.erb
templates/default/default/d3/180
templates/default/default/d3/180/scripts
templates/default/default/d3/180/scripts/d3.profile.erb
templates/default/default/d3/180/tomcat
templates/default/default/d3/180/tomcat/conf
templates/default/default/d3/180/tomcat/conf/catalina.policy.erb
templates/default/default/d3/180/tomcat/conf/catalina.properties.erb
templates/default/default/d3/180/tomcat/conf/clustered-ehcache.xml.erb
templates/default/default/d3/180/tomcat/conf/context.xml.erb
templates/default/default/d3/180/tomcat/conf/d3.properties.erb
templates/default/default/d3/180/tomcat/conf/hpp.properties.erb
templates/default/default/d3/180/tomcat/conf/jaspic-providers.xml.erb
templates/default/default/d3/180/tomcat/conf/jaspic-providers.xsd.erb
templates/default/default/d3/180/tomcat/conf/log4j2_D3Admin.xml.erb
templates/default/default/d3/180/tomcat/conf/log4j2_D3Calls.xml.erb
templates/default/default/d3/180/tomcat/conf/log4j2_D3Carving.xml.erb
templates/default/default/d3/180/tomcat/conf/log4j2_D3Dispatch.xml.erb
templates/default/default/d3/180/tomcat/conf/log4j2_D3IntegrationService.xml.erb
templates/default/default/d3/180/tomcat/conf/log4j2_D3Truck.xml.erb
templates/default/default/d3/180/tomcat/conf/log4j2_D3WebShared.xml.erb
templates/default/default/d3/180/tomcat/conf/logging.properties.erb
templates/default/default/d3/180/tomcat/conf/server.xml.erb
templates/default/default/d3/180/tomcat/conf/shiro.ini.erb
templates/default/default/d3/180/tomcat/conf/shiro_D3Admin.ini.erb
templates/default/default/d3/180/tomcat/conf/tomcat-users.xml.erb
templates/default/default/d3/180/tomcat/conf/tomcat-users.xsd.erb
templates/default/default/d3/180/tomcat/conf/web.xml.erb

Those APIs are all internal and unsupported. If you want to use them, you should familiarize yourself with the relevant Chef internal code first, which will probably help answer your question. This is overall not a supported feature of Chef.

What is the recommended / supported technique for iterating through templates?

What is the recommended / supported technique for iterating through templates?

There isn't one - instead, you should explicitly list the template names. While this does mean you can't simply add a file in the templates folder and have magic happen, this has never really been a problem for me. I've never personally used the solution I wrote in that answer.

I've added a big warning to it now - sorry that it didn't have one when you found it.

It might help if you zoom out and explain the problem you are trying to solve.

Thanks, to step back I inherited this recipe from departed authors.
It is configuring/overwriting tomcat’s “conf” directory with these templates.
They tried to make use of recipe’s template search/subdirectory policy to locate and loop through templates.

The above technique PASSES in a couple of ways…

  1. Bootstrap new centos7 node, then
    $ ssh sudo chef-client
  2. As a developer, via Vagrant in a VirtualBox hosting centos 7.

The above technique FAILS with a compiler error via Vagrant running docker container hosting centos 7; bootstrapping AND configuring via chef-client.

Furthermore, Chef Server does have recipe’s templates as witnessed with command…
$ knife cookbook show D3AppSuite 0.3.213 templates_

So, what could be the difference between a VirtualBox and Docker ?
Could it be the “hostname” causing all of this trouble?

Whereas Vagrant can set the hostname of a VirtualBox guest OS, Vagrantcannot for a Docker container which uses a hash as itshostname.

Does Ohai discover the hostname that chef_client/server uses to locate / find the templates subdirectory?

Does the fully qualified hostname resolve in the docker container? The response to the “hostname” command is not normally enough. It should, ideally, report the right hostname to the “hostname --fqdn” command, which can take a bit more work in DNS or in setting up “/etc/hosts” inside the docker container.

Thanks everyone for your contribution and support.
As suggested, I am going to abandon that technique.
TGIF :blush: