On Wed, Sep 25, 2013 at 5:41 PM, jcbollinger <john.bollin...@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+unsubscr...@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.
