François Chenais
2013-Sep-24 20:31 UTC
[Puppet Users] What''s the best practice to manage software updates using puppet ?
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+unsubscribe@googlegroups.com.
To post to this group, send email to 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.
Dan White
2013-Sep-24 20:45 UTC
Re: [Puppet Users] What''s the best practice to manage software updates using puppet ?
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) ----- Original Message ----- From: "François Chenais" <francois.chenais@gmail.com> To: puppet-users@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 ? 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+unsubscribe@googlegroups.com. To post to this group, send email to 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 . -- 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+unsubscribe@googlegroups.com. To post to this group, send email to 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.
Chris McDermott
2013-Sep-25 13:58 UTC
Re: [Puppet Users] What''s the best practice to manage software updates using puppet ?
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
On Tue, Sep 24, 2013 at 2:31 PM, François Chenais <
francois.chenais@gmail.com> 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+unsubscribe@googlegroups.com.
> To post to this group, send email to 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.
>
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to 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.
Frederiko Costa
2013-Sep-25 15:33 UTC
Re: [Puppet Users] What''s the best practice to manage software updates using puppet ?
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
On Wed, Sep 25, 2013 at 6:58 AM, Chris McDermott
<csmcdermott@gmail.com>wrote:
> 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
>
>
>
> On Tue, Sep 24, 2013 at 2:31 PM, François Chenais <
> francois.chenais@gmail.com> 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+unsubscribe@googlegroups.com.
>> To post to this group, send email to 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.
>>
>
> --
> 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+unsubscribe@googlegroups.com.
> To post to this group, send email to 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.
>
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to 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.
jcbollinger
2013-Sep-25 15:41 UTC
[Puppet Users] Re: What''s the best practice to manage software updates using puppet ?
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 -- 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+unsubscribe@googlegroups.com. To post to this group, send email to 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.
phundisk
2013-Sep-25 17:13 UTC
[Puppet Users] Re: What''s the best practice to manage software updates using puppet ?
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. 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+unsubscribe@googlegroups.com. To post to this group, send email to 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
2013-Oct-31 17:40 UTC
Re: [Puppet Users] What''s the best practice to manage software updates using puppet ?
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.farhadi@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. > > 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+unsubscribe@googlegroups.com. > To post to this group, send email to 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+unsubscribe@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.
devzero2000
2013-Oct-31 20:46 UTC
Re: [Puppet Users] Re: What''s the best practice to manage software updates using puppet ?
On Wed, Sep 25, 2013 at 5:41 PM, jcbollinger <John.Bollinger@stjude.org> wrote:> > > 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. >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 -- 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+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAH5b-BX9ox7A5od-EpDGzmRbD%2BouQMUHGTeiSb7WzqbsxRn%3Dhg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Jason Antman
2013-Nov-01 12:03 UTC
Re: [Puppet Users] What''s the best practice to manage software updates using puppet ?
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.farhadi@currensee.com > <mailto:alex.farhadi@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+unsubscribe@googlegroups.com >> <mailto:puppet-users+unsubscribe@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+unsubscribe@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+unsubscribe@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.