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+unsubscr...@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.
