Upgrading a system that is managed with Chef is as simple as deploying the system with Chef. This stems from the fact, that Chef guarantees idempotency of its runs which means that it converges the Chef resources of a node from an arbitrary state into the desired state. Because this is only guaranteed on the level of Chefs domain specific objects, the recipes containing the resources must implement the idempotency in their resources.
The coremedia cookbook implements idempotence for its recipes concerning
the versions of the installed packages and their configuration. This means, that you only need
to configure the versions you want to install and Chef will install
them on the next run. Due to the implementation of Chefs package
resource, there are two different upgrade strategies:
upgrade to the latest available version, which is default behavior.
upgrade to a specific version.
If you want to upgrade all packages to a specific version, the attribute you need to configure
in your roles is coremedia['version']['global']; if you want to upgrade only
specific packages to a version, you can add an attribute, mapping the package name to the
version aside the global attribute. The example below shows such a configuration:
...
override_attributes "coremedia" => {
"version" => {
"global" => "14-1.release",
"cm7-cms-tomcat" => "14-2.release"
}
}
Example 4.20. upgrading to a specific version
When Chef converges the node, the recipes of the
coremedia cookbook follow a standard process to upgrade the affected
services.
Install the new packages
Restart the services
Verify the successful restart by probing the service with a CoreMedia Probedog
The most important part of this process is the fact, that all service restarts will be scheduled together to the end of the Chef run. This way, a service will only be restarted if all packages could be successfully installed.
 |  |  |
 |