Update your Style in Test Kitchen (Part 2)

It is time for a follow-up to my blog post from last year - especially as Test Kitchen 3.0 changed some defaults. Let’s check some cargo-culted settings out in this blog post.

As any Chef practitioner knows, the web is full of old and outdated info. That is particularly true to Chef, where the first hype around their solutions led to a huge number of blog posts and books.

If you ever worked with fast-changing software, you know how quick info gets outdated. And reading those old blog posts and then copy-and-pasting information from “known good” configurations leads to really bloated projects.

This second part to my series tries to make people aware of some nifty changes in the Chef (and Test Kitchen) universe.

“chef_solo” or “chef_zero”? Well, actually

Surprise! The old-and-trusted chef_zero and chef_solo provisioners are a thing of the past.

While you can still refer to both, chef_zero has merely been an alias to the newer chef_infra provisioner since TK 3.0. And as that is now the default, you would not need to specify a Provisioner name anymore.

Remember to migrate away from chef_solo as well as it provides little to no benefit and still depends on Berkshelf.

Exit Codes

You can see many kitchen.yml (you did update your file names, didn’t you?) files which still have settings around error codes, related to necessary reboots. Often you see a code fragment like this:

provisioner:
  # ...
  retry_on_exit_code:
    - 35
  client_rb:
    exit_status: :enabled
    client_fork: false

Do you have that somewhere? I admit I still found some of those when going through my old cookbooks, so nothing to feel ashamed about.

But… it’s all unnecessary. The retry_on_exit_code statement has actually defaulted to reboot-related exit codes since Test Kitchen v1.19.1 (November 2017!). And those two settings for client_rb have just taken up valuable storage place as they have been obsolete since Chef 13.11

So get rid of this, as we are not living in 2017 anymore :-)

Setting “always_update_cookbooks”

This one is pretty new and a change in Test Kitchen 3.0.0 - before that version, it defaulted to false but now is true 1.

Another line to remove, if you used it.

Minimum TK config

This leaves us with a nice and tiny, modern kitchen.yml file. I also added some ideas of valuable add-ons, if you want to write spotless and upward-compatible cookbooks.

Have fun!

provisioner:
  product_name: chef

  # If you want to know if things wil be deprecated
  # deprecations_as_errors: true

  # If you want to write idempotent recipes
  # enforce_idempotency: true
  # multiple_converge: 2

  # If you have recipes needing more than one reboot (default)
  # max_retries: 5

Similar Posts You Might Enjoy

Update your Style in Test Kitchen

It is surprising how many resources on the Internet are carrying on outdated or deprecated information - the Chef ecosystem is no exception to this. While outdated style in Ruby files has been detected via cookstyle for a while, Test Kitchen files still have no sanity checks yet. Let’s see what changed in this short post. - by Thomas Heinen

Airgapped Testing - VMware Edition

Recently, I got a bug report for the kitchen-vcenter driver, which allows lifecycle management of testing VMs on VMware vCenter environments. Apparently, a customer tried to create a VM without any network interface. The problem was that this crashed in a very unintuitive way. But it made me wonder: Would it be possible to use non-networked machines for tests? It turns out: That’s absolutely possible! - by Thomas Heinen

Third Party Platform Support for Chef

Currently, users of Chef are limited to working with the platforms supported by the Chef core. But with the advancements of Target Mode, the story could change quickly. Learn about the idea of a “Platform Support Pack” and what it could mean for the future. - by Thomas Heinen