How to handle changing url of ChefZero during chef-client run

[JeanMertz]

I'm running into an issue where my Chef run changes the chef-client config during the chef run (see chef-boneyard/chef-client#117). After this change, my cookbooks can no longer connect to ChefZero:

ERROR: Connection refused connecting to https://chef.local.mydomain.com/nodes/server-debian-74, retry 1/5       
ERROR: Connection refused connecting to https://chef.local.mydomain.com/nodes/server-debian-74, retry 2/5       
ERROR: Connection refused connecting to https://chef.local.mydomain.com/nodes/server-debian-74, retry 3/5       
ERROR: Connection refused connecting to https://chef.local.mydomain.com/nodes/server-debian-74, retry 4/5       
ERROR: Connection refused connecting to https://chef.local.mydomain.com/nodes/server-debian-74, retry 5/5       

To handle test environments, I add a conditional resource to my chef run that adds the new chef-server domain to the /etc/hosts file like this:

$ cat /etc/hosts
127.0.0.1 localhost chef.local.mydomain.com

However, this only works on any subsequent runs, not during the initial run where the chef-config is updated mid-run, because ChefZero already started using the original client.rb configs.

I suspect this is due to the fact that ChefZero only listens to a specific url+port, instead of globally listening on any url + port (ie 0.0.0.0:8889). Listening on every ip is probably not the best idea (and seems to be unsupported in test-kitchen anyway), but is there any other option you can think of to solve this issue?

[jaymzh]

What we do is have /etc/chef/client.rb be a symlink. It either points to client-prod.rb or client-test.rb, and we have chef write out client-prod.rb instead of client.rb. Our setup is slightly more complicated, but that's the basic idea.

[JeanMertz]

@jaymzh That's one way to go. But ideally I don't want to know the url beforehand (it is handled by a Chef recipe, based on the environment the Chef run is running in).

[jaymzh]

For the main client.rb? Sure... have Chef write that out that template as /etc/chef/client-prod.rb instead of /etc/chef/client.rb - the fact that Chef writes out that file doesn't have to change. Or am I misunderstanding?

[JeanMertz]

@jaymzh I see what you are getting at, but in my original post I mention the use of the chef-client cookbook. Looking at the way the config-reload is handled, I don't see any way (besides using something like chef-rewind to override the loading of the written config file.

The cookbook writes a client.rb and the loads the configs from that file. There is no way to change this right now.

[jaymzh]

If client.rb doens't suit your environment change it...

vi cookbooks/chef-client/recipes/client.rb

and change line 73 to:

template "#{node["chef_client"]["conf_dir"]}/client-prod.rb" do

Then add:

link "#{node["chef_client"]["conf_dir"]}/client.rb" do
  # let our test processes point this elsewhere for chef-zero testing
  not_if { File.exists?("#{node["chef_client"]["conf_dir"]}/client.rb") }
  to "#{node["chef_client"]["conf_dir"]}/client-prod.rb"
end

[JeanMertz]

Well, of course I can modify the community cookbook, but that's really an anti-pattern. That's why I also mentioned chef-rewind, but I'd rather do this the "proper way", instead of monkey patching a community cookbook using chef-rewind, or worse, forking the community cookbook for personal use.

I did just commit a pull request to add the option not to reload the config. That will solve my issues.

[jaymzh]

That approach means you only get one test-run against your chefzero server. The indirection means that you can do as many test runs as you need until you're ready to revert it.

Modifying cookbooks shouldn't be an anti-pattern... git handles merges very well. :)

[JeanMertz]

Git does. But I just prefer the wrapper-cookbook approach to be on the safe side. And if possible (and it makes sense for others), I'd rather merge changes upstream.

You are right that this approach only gives a single test-run against ChefZero. But I also want this change for other changes unrelated to ChefZero (f.e. one-time changes to be used during a Packer.io machine building process).

Thank you for your valuable input though. It helped me solve the problem eventually.