[chef] Re: Good package install version control -- seeking best approach for postgresql cookbook

[David Crane < >]

That is a great idea. I'm tempted to just do it, but only if I can avoid abandoning opscode-cookbooks/postgresql. I can probably have one of my site-cookbooks/recipes do package upgrades using this approach.

Thanks,

David

From: Kevin Christen < "> >
Reply-To: " "> " < "> >
Date: Saturday, May 4, 2013 8:34 AM
To: " "> " < "> >
Subject: [chef] Re: Good package install version control -- seeking best approach for postgresql cookbook

David,

We take a completely different approach that's worked well. We do not put any package version information in our cookbooks, and always use the :upgrade action in our package resources. We publish RPMs to Artifactory yum repositories, and control package versions by controlling the yum repos that a node installs from.

In your scenario, I'd first publish the new postgresql RPM to a test repo, and test it on a node configured to install from the test repo. Promoting the new version would just require promoting the RPM to a release repository.

Thanks,

Kevin Christen

On Fri, May 3, 2013 at 9:57 AM, David Crane < " target="_blank"> > wrote:

Is there an example of a cookbook that does good package install version control? I.e., that uses node attributes to manage precisely which version of a package is installed? I want to do that in the postgresql cookbook, since it's time to grab an important security update. A simple upgrade to the latest package would be easy to code, but it's not an ideal approach, since a DBA really needs to do careful upgrade planning. It would be best if the cookbook allowed careful control of the installed package versions.

I am hoping someone has already implemented a good package install version control chef design pattern. I have read the documentation for the package resource, but it's not obvious how to assemble the pieces into an all-singing, all-dancing algorithm. 

Here is the situation I now find myself in ...  I wanted 9.2, I got 9.2.3 (actually, 9.2.3-2PGDG.rhel6), and I was happy that the cookbook did that automatically. But now I need to upgrade to 9.2.4, and when I'm done with some rigorous QA testing, I'll need to upgrade in production, but I wouldn't want to go all the way to 9.2.5 yet if there were to be a subsequent patch release.

Here is a bit more detail about what I mean by good package install version control ...  I want to enhance the postgresql cookbook to understand what to do if I change the value of node['postgresql']['version'] from '9.2' to '9.2.4'. I would not want to have to specify the complete version-release specification of '9.2.4-1PGDG.rhel6' in my node attributes, because that would be a ghastly level of detail. Ideally, the cookbook would understand that '9.2' means it should be happy with any minor 9.2.X release so that a DBA initially interested in the current 9.2.X  cookbook didn't later find that chef unexpectedly does a software upgrade on their production database five minutes after the package maintainer pushes a patch. 

========

If there's not an existing cookbook pattern I can follow, I would be able to code this myself. I would need to learn more about how the package resource treats its version attribute ...

Since the postgresql cookbook actually has separate server_debian.rb and server_redhat.rb recipes, I read up on the Redhat-specific version of the package resource. The documentation (http://docs.opscode.com/resource_yum.html) which gives examples of partial minimum version  and specific version-release, but nothing in between. Also a variety of code approaches. For example:

    yum_package "netpbm >= 10"

    yum_package "netpbm" do
      version "10.35.58-8.el5"    end  

Since Debian and SUSE users are using the postgresql cookbook and submitting pull requests to the opscode-cookbooks, I'd rather do this with the distribution-agnostic package resource so that all can benefit. The documentation (http://docs.opscode.com/resource_package.html) gives an example snippet with a specified version, but doesn't explain the subtleties about what happens with '9.2' vs '9.2.4':

    package "mysql-server" do
      version node['mysql']['version']
      action :install    end

========

What's a noob to do?

Thanks for any advice,

David Crane