best way to ensure (yum) package repository freshness ?

[Daniel Maher]

Hello,

I have run into problems in the past where a package has been added to
our yum repository, and a (new) class has been pushed to install that
package, but puppet fails because the yum db on the target machine is
too stale, and thus isn't aware of the existence of the new package.

My question is this : what have other Puppet admins done in order to
ensure that a target machine has the freshest local dbcache before
attempting to install a package ?

Thank you.

--
Daniel Maher <dma AT witbe DOT net>
"The Internet is completely over." -- Prince

[Ian Ward Comfort]

On 18 Nov 2010, at 12:56 AM, Daniel Maher wrote:
> I have run into problems in the past where a package has been added to our yum repository, and a (new) class has been pushed to install that package, but puppet fails because the yum db on the target machine is too stale, and thus isn't aware of the existence of the new package.
>
> My question is this : what have other Puppet admins done in order to ensure that a target machine has the freshest local dbcache before attempting to install a package ?

We haven't run into this problem here, but I imagine something like the following (untested) code might help:

exec { 'yum-clean-expire-cache':
user => 'root',
path => '/usr/bin',
command => 'yum clean expire-cache',
}

Package { require => Exec['yum-clean-expire-cache'] }

package { ['foo','bar']: ensure => present }

That should make Puppet revalidate all of yum's caches before attempting to install either the foo or bar packages (or any packages for which the above resource default is in scope). 'yum clean expire-cache' is the cheapest way to ensure an updated view of your yum repos, without deleting too much metadata which may need re-downloading in case the repos are unchanged. Note that this clean would happen on every Puppet run, of course, and that may not be desirable.

--
Ian Ward Comfort <icom...@stanford.edu>
Systems Team Lead, Academic Computing Services, Stanford University

[Trevor Hemsley]

Perhaps you could adjust one of the /etc/yum.conf parameters like metadata_expire down from its default of 1.5 hours or keepcache = false (not entirely sure that this one does what you want it to do). The metadata_expire one can be set at the repo level so you could set it only for your own repo.

On 18/11/2010 08:56, Daniel Maher wrote:

Hello,

I have run into problems in the past where a package has been added to our yum repository, and a (new) class has been pushed to install that package, but puppet fails because the yum db on the target machine is too stale, and thus isn't aware of the existence of the new package.

My question is this : what have other Puppet admins done in order to ensure that a target machine has the freshest local dbcache before attempting to install a package ?

Thank you.

--

Trevor Hemsley
Infrastructure Engineer
.................................................
C A L Y P S O
Brighton, UK   

OFFICE	+44 (0) 1273 666 350
FAX	+44 (0) 1273 666 351

.................................................
www.calypso.com

This electronic-mail might contain confidential information intended only for the use by the entity named. If the reader of this message is not the intended recipient, the reader is hereby notified that any dissemination, distribution or copying is strictly prohibited.

P Please consider the environment before printing this e-mail

[Patrick]

On Nov 18, 2010, at 12:56 AM, Daniel Maher wrote:

> Hello,
>
> I have run into problems in the past where a package has been added to our yum repository, and a (new) class has been pushed to install that package, but puppet fails because the yum db on the target machine is too stale, and thus isn't aware of the existence of the new package.
>
> My question is this : what have other Puppet admins done in order to ensure that a target machine has the freshest local dbcache before attempting to install a package ?
>
> Thank you.

What ever you do, you will probably want to make sure you have a caching proxy server (or an on site mirror) between your clients and the yum server.

[jcbollinger]

On Nov 18, 2:56 am, Daniel Maher <d...@witbe.net> wrote:
> My question is this : what have other Puppet admins done in order to
> ensure that a target machine has the freshest local dbcache before
> attempting to install a package ?

I set up a cron job (via Puppet) that periodically performs a "yum
clean all". That's a bit crude, and it allows for a delay before a
new package is recognized and installed, but it works well enough for
me.


John

[Sam Coffland]

I came a across this post and like what I see but would off the following addition to Ian's suggestion so that the expire cache  is not executed on every puppet run. 

exec { 'yum-clean-expire-cache':

          command => '/usr/bin/yum clean expire-cache',

          refreshonly => true,

}

package { ['foobar']: 

         ensure => present,

         require => Exec['yum-clean-expire-cache',

[daddy dp]

I also faced with same problem and setting metadata_expire to 1 minute works for me. Schedule yum clean in puppet run is not good idea, because you always get at least one resource changed, and never will green nodes in puppet dashboard.

[jcbollinger]

On Monday, September 29, 2014 2:28:02 PM UTC-5, Sam Coffland wrote:

I came a across this post and like what I see but would off the following addition to Ian's suggestion so that the expire cache  is not executed on every puppet run. 

exec { 'yum-clean-expire-cache':

          command => '/usr/bin/yum clean expire-cache',

          refreshonly => true,

}

package { ['foobar']: 

         ensure => present,

         require => Exec['yum-clean-expire-cache',

}

Nope.  At least not by itself.  Marking the Exec with refreshonly => true makes it run its command if it receives at least one Event from a modified resource (and not otherwise), but nothing shown sends it any events.  Instead of the Exec running every time, it would never run.  I suppose the idea was that Package resources would send the events, but

1. Packages are applied after the Exec, which is too late.
2. If the Packages were applied before the Exec, then Puppet would use cached data to determine whether they need updated, which is exactly what we want to avoid.

John