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.farh...@currensee.com
<mailto:alex.farh...@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.
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.
On Tuesday, September 24, 2013 4:31:10 PM UTC-4, 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 ...
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
--
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+unsubscr...@googlegroups.com
<mailto:puppet-users+unsubscr...@googlegroups.com>.
To post to this group, send email to puppet-users@googlegroups.com
<mailto:puppet-users@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/
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/30F8BCC6-5975-47C2-A574-2C54B67C5E71%40netconsonance.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/52739877.5050002%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.
