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


#1

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.htmlhttp://docs.opscode.com/resource_package.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


#2

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 davidc@donorschoose.org 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.htmlhttp://docs.opscode.com/resource_package.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


#3

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 <kevin.christen@gmail.commailto:kevin.christen@gmail.com>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Saturday, May 4, 2013 8:34 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
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 <davidc@donorschoose.orgmailto:davidc@donorschoose.org> 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.htmlhttp://docs.opscode.com/resource_package.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


#4

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

From: Kevin Christen <kevin.christen@gmail.com <javascript:_e({}, ‘cvml’,
‘kevin.christen@gmail.com’);>>
Reply-To: "chef@lists.opscode.com <javascript:_e({}, ‘cvml’,
‘chef@lists.opscode.com’);>" <chef@lists.opscode.com <javascript:_e({},
‘cvml’, ‘chef@lists.opscode.com’);>>
Date: Saturday, May 4, 2013 8:34 AM
To: "chef@lists.opscode.com <javascript:_e({}, ‘cvml’,
‘chef@lists.opscode.com’);>" <chef@lists.opscode.com <javascript:_e({},
‘cvml’, ‘chef@lists.opscode.com’);>>
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 davidc@donorschoose.orgwrote:

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.htmlhttp://docs.opscode.com/resource_package.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


#5

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 webmat@gmail.com 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

From: Kevin Christen kevin.christen@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Saturday, May 4, 2013 8:34 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
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 davidc@donorschoose.orgwrote:

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.htmlhttp://docs.opscode.com/resource_package.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