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

**URL:** <https://discourse.chef.io/t/good-package-install-version-control-seeking-best-approach-for-postgresql-cookbook/4002>\
**Category:** Chef Infra (archive)\
**Created:** [May 3, 2013, 2:57pm UTC](https://discourse.chef.io/t/good-package-install-version-control-seeking-best-approach-for-postgresql-cookbook/4002 "2013-05-03T14:57:47Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![David\_Crane](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/david_crane/32/546_2.png) [@David\_Crane](https://discourse.chef.io/u/David_Crane)\
**Post date:** [May 3, 2013, 2:57pm UTC](https://discourse.chef.io/t/good-package-install-version-control-seeking-best-approach-for-postgresql-cookbook/4002/1 "2013-05-03T14:57:47Z")

</div>

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](http://docs.opscode.com/resource_yum.html)[http://docs.opscode.com/resource\_package.html](http://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](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

---

<div class="post-metadata">

**Author:** ![Kevin\_Christen](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kevin_christen/32/479_2.png) [@Kevin\_Christen](https://discourse.chef.io/u/Kevin_Christen)\
**Post date:** [May 4, 2013, 12:34pm UTC](https://discourse.chef.io/t/good-package-install-version-control-seeking-best-approach-for-postgresql-cookbook/4002/2 "2013-05-04T12:34:52Z")

</div>

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](mailto: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.html](http://docs.opscode.com/resource_yum.html)[http://docs.opscode.com/resource\_package.html](http://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 ([package Resource](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

---

<div class="post-metadata">

**Author:** ![David\_Crane](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/david_crane/32/546_2.png) [@David\_Crane](https://discourse.chef.io/u/David_Crane)\
**Post date:** [May 6, 2013, 4:33pm UTC](https://discourse.chef.io/t/good-package-install-version-control-seeking-best-approach-for-postgresql-cookbook/4002/3 "2013-05-06T16:33:11Z")

</div>

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](mailto:kevin.christen@gmail.com)[mailto:kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)\>  
Reply-To: "chef@lists.opscode.com[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)" \<[chef@lists.opscode.com](mailto:chef@lists.opscode.com)[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)\>  
Date: Saturday, May 4, 2013 8:34 AM  
To: "chef@lists.opscode.com[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)" \<[chef@lists.opscode.com](mailto:chef@lists.opscode.com)[mailto:chef@lists.opscode.com](mailto: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.org](mailto:davidc@donorschoose.org)[mailto:davidc@donorschoose.org](mailto: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.html](http://docs.opscode.com/resource_yum.html)[http://docs.opscode.com/resource\_package.html](http://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](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

---

<div class="post-metadata">

**Author:** ![Mathieu\_Martin](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/mathieu_martin/32/60_2.png) [@Mathieu\_Martin](https://discourse.chef.io/u/Mathieu_Martin)\
**Post date:** [May 6, 2013, 9:18pm UTC](https://discourse.chef.io/t/good-package-install-version-control-seeking-best-approach-for-postgresql-cookbook/4002/4 "2013-05-06T21:18:14Z")

</div>

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](mailto:kevin.christen@gmail.com) \<javascript:\_e({}, 'cvml',  
> 'kevin.christen@gmail.com');\>\>  
> Reply-To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com) \<javascript:\_e({}, 'cvml',  
> 'chef@lists.opscode.com');\>" \<[chef@lists.opscode.com](mailto:chef@lists.opscode.com) \<javascript:\_e({},  
> 'cvml', 'chef@lists.opscode.com');\>\>  
> Date: Saturday, May 4, 2013 8:34 AM  
> To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com) \<javascript:\_e({}, 'cvml',  
> 'chef@lists.opscode.com');\>" \<[chef@lists.opscode.com](mailto: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.org](mailto: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.html](http://docs.opscode.com/resource_yum.html)[http://docs.opscode.com/resource\_package.html](http://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 ([package Resource](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

---

<div class="post-metadata">

**Author:** ![Jens\_Skott](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jens_skott/32/492_2.png) [@Jens\_Skott](https://discourse.chef.io/u/Jens_Skott)\
**Post date:** [May 7, 2013, 4:30am UTC](https://discourse.chef.io/t/good-package-install-version-control-seeking-best-approach-for-postgresql-cookbook/4002/5 "2013-05-07T04:30:19Z")

</div>

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](mailto: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](mailto:kevin.christen@gmail.com)  
> > Reply-To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com)" [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> > Date: Saturday, May 4, 2013 8:34 AM  
> > To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com)" [chef@lists.opscode.com](mailto: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.org](mailto: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.html](http://docs.opscode.com/resource_yum.html)[http://docs.opscode.com/resource\_package.html](http://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 ([package Resource](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