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


Chronological Thread 
  • From: David Crane < >
  • To: chef < >
  • Subject: [chef] Good package install version control -- seeking best approach for postgresql cookbook
  • Date: Fri, 3 May 2013 10:57:47 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

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



Archive powered by MHonArc 2.6.16.

§