Users should be able to automatically upgrade to the desired version of chef without having to use third party cookbooks. The upgrade should occur without affecting the normal chef client run, ensuring that a consistent state is preserved.
As an operator, I want chef versions to be consistent across my infrastructure, so that I can ensure my code works correctly
As an operator, I want to easily and safely upgrade chef to my desired version, so that I can easily roll out new versions.
As a developer, I want our users to get new features and bug fixes in a timely and safe manner, so that everyone's happy.
At the beginning of each chef run, the client should decide whether or not to upgrade, based on configuration supplied by the administrator.
If the administrator has specified a version of chef different to the one currently running, the chef client should check with an update service to ensure the specified version is available. If so, the client will download the specified version, and install it appropriately. The client run will then exit with exit code 213 to signal an upgrade has occurred as defined in RFC 62.
The desired chef version should be provided to the node through a new first class environment or node attribute tree, named
__chef_upgrade__. Once RFC 45 is completed, that attribute tree will be marked as desired state, and not mutable by the node.
The attribute tree will contain one mandatory attribute,
some additional attributes. Currently, we intend to support
to allow the administrator to specify that they would like to consume
unreleased builds. Channels are documented in RFC 47.
version attribute shall contain either MAJOR, MAJOR.MINOR, or
MAJOR.MINOR.BUILD as documented in RFC 47.
It can also be the special string "latest", signifying that the node
should always upgrade to the latest available version.
Currently, Chef provides an omnitruck API service that allows one to query for versions of packages. The API is documented, and provides the ability to request various groups of versions. In future it may be desirable to provide a similar API in the Chef Server, to provide upgrades to nodes that have no external connectivity.
The chef client will use the most appropriate mechanism to install the latest version of chef. The chef client will then exit with an appropriate error code, allowing the parent process to restart gracefully.
Given the environment below:
A chef client on an ubuntu node in the
production environment, will make a request to omnitruck:
and receive metadata containing the latest package in the
Should that package be newer than the current version, chef will download
the deb package, install it via
dpkg, and end the chef run with a suitable
This work is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work.