What's the best practice to manage software updates using puppet ?

[François Chenais]

Hello,

I got many classes, using the well known template ...

  package
     ensure => XXX
     notify => service

  file
     require => package
     notify => service

  service
     require => File, Package


... with ensure value XXX set to 'latest'.


This implies that package could be updated when I change a value
in config file even if I don't want to update it  ... especially in production ...

A solution can be changing all ensure value to 'present' or 'installed' but I'm not
the owner of the code so I would like to know if there is a way to

- deactivate the package update through a command line option ?
- change the ensure value using

  - a command line option
  - a fact
  - a tag
  - ???



More generally, what's the best practice to manage software updates using puppet :

- ensure => present   
- fix pkg repositories   :/
- ???


Thanks a lot


     François

 

[Dan White]

I just use "ensure => present"

I manage versions with yum (Red Hat Enterprise 5)
But puppet does manage my yum repository configuration.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

---

From: "François Chenais" <francois...@gmail.com>
To: puppet...@googlegroups.com
Sent: Tuesday, September 24, 2013 4:31:10 PM
Subject: [Puppet Users] What's the best practice to manage software updates using puppet ?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Chris McDermott]

I haven't found a solution that I'm totally happy with either, but what I've done in a few cases is specify particular versions with ensure. Like this:

$varnish_version = $::environment ? {

  'dev'      => '3.0.4-1.el6',

  'staging => '3.0.4-1.el6',

  'prod'     => '3.0.3-1.el6',

}

package { 'varnish':

  ensure => $varnish_version

}
package { 'varnish-libs':
  ensure => $varnish_version,
}
package { 'varnish-libs-devel':
  ensure => $varnish_version,

}

Obviously you can't do that for every package installed on your hosts, but it works if you're only managing a small number with puppet. You need to watch out for dependencies though. Then to update your prod environment, for instance, you can just update the version string to match dev and staging. You could also move the version strings out into hiera, and manage them there, so all package version data is in one place.

Chris

[Frederiko Costa]

What I particularly do is to make sure that every module has the $package_ensure class parameter set to 'present' by default. If I want a particular version, then I tell when I instantiate the class. One example would be:

class a($package_ensure = 'present') {

   package { 'whatever-a' :

      ensure => $package_ensure,

      ....

   }

}

On my nodes.pp or Hiera you could say:

node 'host-a' { 

  include a

}

node 'host-b' { 

  class { 'a' :

     package_ensure => '1.1.2',

  }

}

That's the way I manage here. It's been working okay so far. I great help is to have your own yum/apt repositories, so you manage versions in a more controlled approach.

I hope it helps.

-frederiko

[jcbollinger]

On Tuesday, September 24, 2013 3:31:10 PM UTC-5, François Chenais wrote:

Hello,

I got many classes, using the well known template ...

  package
     ensure => XXX
     notify => service

  file
     require => package
     notify => service

  service
     require => File, Package


... with ensure value XXX set to 'latest'.


This implies that package could be updated when I change a value
in config file even if I don't want to update it  ... especially in production ...

Not exactly.  It declares that the package should be updated whenever there is a more recent version available, regardless of whether you change any configuration.  Any dependency on configration change is externally imposed, such as if you only apply such a class when you have in fact made config changes.

 

A solution can be changing all ensure value to 'present' or 'installed' but I'm not
the owner of the code so I would like to know if there is a way to

- deactivate the package update through a command line option ?
- change the ensure value using

  - a command line option
  - a fact
  - a tag
  - ???

If you cannot change the manifest code, then the only way to apply the class in the presence of an available update without in fact updating the package would be to include a parameter override somewhere in the catalog.  You will need to add code to do that, but it doesn't have to be in the class in question.  I'm not aware of a way to switch such behavior based on tags or command-line options, but you control whether such an override is applied by testing a custom fact.

An override would have this form:

class blah::noupdate inherits blah {
  Package['blah'] {
    ensure => 'present'
  }
}

or

Package<| name == 'blah' |> {
  ensure => 'present'
}

The former can only be done via a subclass of the class declaring the package, as shown, whereas the collector-based form is not restricted in that way.

Under some circumstances it might even make sense to do something like this

Package<| ensure == 'latest' |> {
  ensure => 'present'
}

More generally, what's the best practice to manage software updates using puppet :

- ensure => present   
- fix pkg repositories   :/
- ???

My above comments notwithstanding, there is much to be said for maintaining local repositories and pointing your clients exclusively at those.  In addition to giving you the ability to control what packages and what versions can be installed (not just by Puppet), it also removes your day-to-day reliance on third-party repository providers, and in many cases it will give you better performance for package installations and updates.  It may not solve your problem if you want to maintain different machines with different versions of the same package, but even then it's probably worth doing.


John

[phundisk]

For me, when I was deciding to manage updates, there were two options for me.

1. Set everything to ensure latest and only use clones of centos/redhat repos for different environments such as QA, and production.  The downside of here is that you need to manage every package in puppet, you will probably miss some.

2. Just use ensure => present and use another solution such as spacewalk or satellite to manage updates.  That is what I choose personally.  It works out pretty good so far.

[Jo Rhett]

There's always the alternative of using "ensure => heira( 'package_version', present )" and using hiera to control the software release. If you're doing this you want osfamily in the hiera structure. I've found this much superior to either of the following two choices.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

Author of Instant Puppet 3 Starter: http://www.netconsonance.com/instant-puppet-3-starter-book/

[devzero2000]

My experience and knowledge tell me that every tool should be used for
the purpose for which it was born. A system configuration system is
different from a package management system which is different from a
centralized software management system. For me, using puppet for
making patch management means to go in search of trouble, as using
puppet as a package managent system, it is easy to lose control.
Managing software dependencies with puppet, hardwiring specific
version doesn't work in the long run. But the Various tools can be
orchestrated, of course.

For a centralized software management tool something as spacewalk
should be used.

My 2cent


Best regards

[Jason Antman]

We use largely the same solution as Jo but with an ENC.

Packages that we really don't care about are usually just ensure => present, so every machine built from a given release should have the same version (upgrades because of dependencies aside), or ensure => latest in the rare case that we've decided it's trivial or stable enough to allow automatic updates.

For anything that we care about, we install using a parameterized class, that exposes a package_version parameter which we explicitly set to a version in our ENC. For testing/QA, we override that parameter on a host or group level to a newer version, and once it's validated, we change the version in the "default" environment. (Well actually, that's how it works in our new puppet3 infrastructure, currently being rolled out, which uses an in-house Django-based ENC. In our "old" puppet infrastructure that uses Puppet Dashboard, we have a *bunch* of parameters (which show up in puppet as globals) set on groups or nodes, like "postgres_version" or "httpd_package_version").

-jantman

On 10/31/2013 01:40 PM, Jo Rhett wrote:

There's always the alternative of using "ensure => heira( 'package_version', present )" and using hiera to control the software release. If you're doing this you want osfamily in the hiera structure. I've found this much superior to either of the following two choices.

On Sep 25, 2013, at 10:13 AM, phundisk <alex.f...@currensee.com> wrote:

For me, when I was deciding to manage updates, there were two options for me.

1. Set everything to ensure latest and only use clones of centos/redhat repos for different environments such as QA, and production.  The downside of here is that you need to manage every package in puppet, you will probably miss some.

And that you'll need to keep clones of the repos for each environment, which AFAIK is about 100G per environment.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/30F8BCC6-5975-47C2-A574-2C54B67C5E71%40netconsonance.com.