Coming soon: Chef Client 14 and Chef Development Kit 3

Chef Infra (archive)
1

At Chef, we understand that Infrastructure Automation enables your business to succeed, but it isn’t the reason your business exists. Ultimately, all software is a careful balancing act of introducing new features, fixing bugs, and saying no to ideas that we might love to do but are too disruptive–and it’s up to us to ensure that our work doesn’t create too much work for you. To ease that burden and help you plan for updates, we’ve introduced a regular release cadence, with backwards compatible releases of Chef Client each month, and a yearly “major” release that may remove old, confusing or dangerous functionality.

With that in mind, we’re very excited to announce that we’ll be releasing Chef Client 14 and Chef Development Kit 3 in April 2018. Chef Client 14 continues the themes that Chef Client 13 introduced, concentrating on ensuring the safety, correctness, and performance of your cookbook code, while introducing many new resources and improved functionality. The ChefDK 3 release will feature the latest and greatest versions of all your favorite Chef developer tools. We will cover these in-depth in a future blog post.

What to expect in Chef Client 14

We’re still laser focused on making writing Custom Resources enjoyable and fast. With that in mind we’re intending to do considerable work on ChefSpec to make it much easier to test custom resources, we’re going to work on our logging so cookbook authors and operators can get exactly the information they need to reason about their Chef Client runs, and we’re going to make it easier to integrate with MySQL and PostgreSQL out of the box.

We will be removing some older behaviors that we found to cause errors in cookbooks. To see a list of these removals, our Deprecations page is continually updated, and Foodcritic will already issue warnings for the changes we’re introducing in Chef Client 14.

We’re also planning on adding a number of frequently used resources. When we think about adding a resource, we examine how stable the resource is (and how frequently the thing it controls changes), how often it’s used, and whether it’s supportable. Including new resources allows you to do more things out of the box, speeding up the development experience and making it easier to choose the best approach to a problem. Some of the resources we’re thinking about adding include:

  • docker_container, docker_registry, docker_exec, and docker_network
  • ohai_hint and chef_handler, for easier cookbook development
  • dmg_package, homebrew_cask, and homebrew_tap for macOS support
  • windows_font, powershell_module, and a few other Windows resources

Chef Client 12 and ChefDK 1 EOL

April 2018 also brings the End of Life of Chef Client 12, nearly four years after its release in December 2014. We understand that for many of you, Chef Client 12 continues to “just work”. However behind the curtains, it’s becoming technologically outdated and less secure. Much of the software that is contained in the Chef Client 12 packages has also become end of life, meaning that we can no longer offer security releases should a vulnerability in (for example) Ruby be found. Continuing to support Chef Client 12 also makes life harder for our community of cookbook authors, requiring them to support a broad set of capabilities. Along with Chef Client 12, ChefDK 1 will also become End of Life and will cease to be updated or supported. Today, we are releasing a new online resource with an overview of the EOL process and resources to ease the transition to Chef 13/14.

Chef 14 discussion and Chef 12 migration

We expect that Chef Client 14 will be the easiest to use and most featureful release we’ve made, and we can’t wait to get it in your hands. Over the next six months watch this space for additional resources to get the most out of Chef 14/CDK 3, and to ease your transition from Chef 12. Finally, we’d also love your feedback on our plans, and especially the set of resources we’re planning on shipping. We have a new official Slack channel for Chef 14 discussion and help with Chef 12 client migration. Join the #Chef-14 channel in our Chef Community Slack at community-slack.chef.io. This channel is actively monitored by Chef employees and community members who look forward to answering your questions and helping make your migration a success.

2 Likes
3

The Docker resource would be great, but please support Singularity as well. It’s important for HPC environments where it doesn’t make sense and is not safe to use Docker. We would like to use Chef to help create and/or test these containers.

4

Hey @jekriske,
I’ve not really come across Singularity before. Is there a cookbook that has resources to manage Singularity? In general we’d like to see the resources really shaken down in a cookbook before we bring them in to core.
Cheers,
-Thom

5

@thommay Nope, there’s not a cookbook so far. At least not in the supermarket and that’s the issue. I haven’t had a chance to create one, but even if I did, it wouldn’t be as full featured as cookbooks from Chef generally are. I guess it doesn’t matter so much if it’s in the Chef core or in the supermarket (supported by Chef).

http://singularity.lbl.gov/user-guide

You’d hear about it at computing conferences and high performance computing publications such as:

  • Supercomputing 2017 (See any of the presentations mentioning containers)
  • Intel® HPC Dev Conference 2017 (Greg Kurtzer is giving a talk)
  • Here’s an article on HPC wire

Institutions that provide multi-user computing environments would be far more likely to use Singularity than Docker due to inherent security issues with Docker, its supervisor constantly running, and lack of reproducibility when using tags to pull or run. In regulated environments this can be very important. It’s a very different use case than typical enterprise computing with web servers, databases, and such.

We use Chef, not just to manage infrastructure, but to build hundreds of software titles, from source, on our cluster. As we move toward containerization of applications and/or entire workflows to deal with dependency issues, future reproducibility, and cloud bursting, it’d be nice if Chef could help manage creation, manipulation, or running of the containers. If not, then it’d just be a mess of partially idempotent execute resources. :face_with_raised_eyebrow:

It’s something to take a look at.

Thanks,
-Jeff

6

The path we’ve generally followed for adding new Resources to Chef is to
build them out in a cookbook (ie. windows or docker cookbooks) with a
couple of releases and incorporate the ones that prove most popular. I’d
love to see a Singularity cookbook in the community and get the features
and custom resources fleshed out first. Perhaps there are other community
folks who are interested who could followup on this thread?

Thanks,
Matt Ray
Manager, Solutions Architect - APJ :: Chef
matt@chef.io
AUS: +61 457 231 372
US: +1 512 731 2218
mattray :: GitHub :: IRC :: Slack :: Twitter

7

I really like the ChefSpec testing of resources. ChefSpec for me has not been useful but I’d love a streamlined way to get value out of it quickly with resource development.