Fixing repeated node changes on yumcache by making this a refreshonly

[ahuffman]

My nodes were executing the yum_make_cache repeatedly even though they completed successfully previously on every puppet run. This will correct that issue.

[spuder]

I would like to see this get merged, but I'm not sure how this pull request will change anything.
refreshonly causes the resource to only be executed if it is triggered from a notify or a subscribe

https://docs.puppetlabs.com/references/latest/type.html#exec

I could be wrong, but I don't see how the "yum_make_cache_${repo_name}" resource is ever given notice. I suspect the manifest will also need something like this

      subscribe   => File["${normalized_name}"],

That way if the file ever does get updated, it will refresh the cache.

[ahuffman]

@spuder You're correct. I made that change and pushed the change.

[ahuffman]

I decided to do some more work on this to appropriately utilize yumrepos and puppetlabs-apt. I've tested the CentOS changes, but have not tested the Debian/apt code. Someone want to try it out?

[ahuffman]

Any thoughts on this pull request. The module is really not very usable currently in a production environment if the node is going to change every single puppet run.

[ice799]

Hi:

I'm filling in my thoughts about this here so that anyone following can understand my reasoning.

If refreshonly is added then new packages which are uploaded after the yum cache has been regenerated will not be able to be installed unless a cache refresh is done manually (via cron, command line, whatever) or in puppet.

This breaks a major use case of packagecloud -- many people upload software artifacts to their repositories throughout the day as part of their continuous integration and delivery pipelines and changing this would break their ability to install the latest versions of their software on each puppet run.

I'm open to changing this in some fashion, but we must preserve this use case.

As far as using the yumrepo resource, I cannot merge any changes that uses yumrepo because some versions of yumrepo do not have the repo_gpgcheck option which is required for securely using packagecloud repositories. Using this built-in resource prevents users on earlier versions of puppet from securely using packagecloud repositories.

[ahuffman]

I suggest adding some logic for that use case. if $::puppetversion <= $theolderversion {
#old code
}
else {
#yum/apt repos

}

Or to keep it clean split the module into 2 versions.

[spuder]

What if you add a new manifest that forces an update of the cache.
That way, people who want to use the repos normally, get the expected behavior, and the people who want CI, can simply pass a parameter into the module to force updates every puppet run.

Something like

packagecloud::repo { "username/publicrepo":
  type => 'rpm',
  force_refresh => 'true',
}

Then you would have a refresh.pp manifest with an exec in it

exec {'yum update cache':
  do stuff
}

In your init.pp, have a condition.

if { "::packagecloud::force_refresh }
  include refresh.pp
  Class[refresh]
end

ahuffman has a good idea on the yumrepo resource. You would still need to add it as a dependency, but you could have a decision tree based on the puppet version.

If using the stdlib library

 if versioncmp($::puppetversion, '3.0.0') < 0 {
    fail("Module requires puppet 3.0.0 or greater, found: \'${::puppetversion}\'")
  }

Plain old facter

  if $::puppetversion <= '3.0.0' {
    fail("Module requires puppet 3.0 or greater, you have ${::puppetversion}")
  }

[mvisonneau]

The purpose of Puppet code is to be idempotent which is not the case right now. This should definitely be merged in my opinion.