Managing (and pinning) package versions with puppet

[Andres Olarte]

I have an installation that I'm trying to manage with puppet. For some of the packages we want to have very tight control over the versions. Since they are critical to our application, we only upgrade them after testing in our test environment, and we schedule upgrades during low traffic times. I don't want puppet to upgrade my database whenever a new package appears. I specified the version in my puppet manifest to prevent the package from automatically upgrading, however when I went to generate another instance using the same config, that version of the package was gone from the Ubuntu repo. Only the more recent ones are there.

For some of the packages, I've been packing them myself into my own repo, however packaging the database (postgresql) has proven too be too much overhead.

Any solutions or ideas?

We're using Ubuntu 12.04.1 LTS.

Thanks,

Andres

[Ken Chida]

Why not do:

package {'foo':

    ensure => present

}

This will only ensure that some version of 'foo' is installed.  Also, I've found that excessive pinning slows down 'apt-cache policy', which puppet appears to run for each package resource.  I've improved puppet runs by an order of magnitude by removing pins.

-Ken

[Jakov Sosic]

You can keep local copy of ubuntu repos, which you could update only
when you choose to, or you can have your own local repo in which you
will copy only postgresql related pacakges (if it's only postgresql
which is being a problem).

[Rajat Patel]

In my opinion the version and/or holdable features should be re-implemented as a new variable, such as:

package { 'apache2'
  ensure => installed,
  version => '2.0.64',
  hold => true,
}

Rajat

[jcbollinger]

On Monday, June 17, 2013 5:05:41 AM UTC-5, Rajat Patel wrote:

In my opinion the version and/or holdable features should be re-implemented as a new variable, such as:

package { 'apache2'
  ensure => installed,
  version => '2.0.64',
  hold => true,
}

 
Would you care to comment on why you think that would be better?  A specific version number is a special case of 'hold', which itself is a special case of 'installed'.  Splitting them out as separate parameters would create the opportunity for them to be inconsistent, and I don't see anything useful to be gained in return.


John