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

[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.