I've run into a very interesting edge case which temporarily breaks Chef when switching Chef servers using a bootstrap process.
A little background, to explain... for security reasons, my company is splitting our networks into Prod and Non-Prod spaces, which won't be able to talk to each other. I'm preparing our infrastructure by creating a non-prod Chef server which matches most of our existing prod Chef server.
The cookbooks, recipes, roles, etc. are identical between the two systems (yay for Infrastructure as Code - just push up the data!). So telling (for example) a QA node to switch over from the prod server to the non-prod one involves:
- Removing the node from the prod server (knife client delete NODE --profile prod, knife node delete NODE --profile prod).
- Bootstrap the node from the non-prod server (knife bootstrap NODE AUTH HERE --profile nonprod).
Simple and clean. Works just fine under Windows. But because of how the Chef Client runs in Linux, it actually causes issues.
After the bootstrap, the old chef-client daemon is still running - and loaded using the old client.rb configuration, which is now pointing at the wrong server.
All I have to do to fix this is the bounce the chef-client service, but it would be nice if the bootstrap process was able to handle this. It's able to tell that there's an existing Chef installation, so it should be a simple matter of triggering a daemon restart at the end of the run.