General discussion about Chef

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


Chronological Thread 
  • From: Jens Skott < >
  • To: " " < >
  • Subject: [chef] Re: Re: Good package install version control -- seeking best approach for postgresql cookbook
  • Date: Tue, 7 May 2013 06:30:19 +0200
Yes, the satellite does package mirroring, the way we have set it up is that we have cloned the base channel into test, and a stage from that test channel and a prod from that stage channel. All nodes are connected to the test stage and the prod channels, noone to the "live" channel. That way we are in full control of what packages are delivered to the servers at all times. 




Jens Skott 
Tel: +46-8-5142 4396
Schibsted Centralen IT



On Mon, May 6, 2013 at 11:18 PM, Mathieu Martin < " target="_blank"> > wrote:
FWIW, just today I was discussing Spacewalk / Satellite For the RedHat family of OSes.

From what I understood, it does package mirroring (where you override only the parts you care about), but also some part of provisioning and even longer term management (e.g. packages installed on different nodes).

May be worth looking into as well.

HTH,

Mat


On Monday, May 6, 2013, David Crane wrote:
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


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 < > 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


--
Rock Solid Ops: development & operations consulting for Ruby on Rails


Archive powered by MHonArc 2.6.16.

§