Flush yum cache

[petre]

Description

Flush yum cache before installing the sensu rpm package.

Motivation and Context

Chef caches the yum package database in memory in order to speed up recipe execution. When updating the sensu version attribute, sometimes chef fails because it doesn't recognize the version.

How Has This Been Tested?

ran kitchen converge and verify on default-centos-68 and default-centos-73 platforms

Screenshots (if appropriate):

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.

[thomasriley]

Hey @petre, thank you for your contribution!

I have had a look into this and I can see that setting the flush_cache property does not flush the yum cache as you say, it instead flushes the copy of the yum cache that Chef stores in-memory. Therefore I'm concerned that this may not have the affect that you are hoping for.

May I suggest it would be worth raising an issue on this repository with some details on the issue you are seeing (including any error output), how it can be replicated & some details on your chef environment?

Cheers, Tom.

[petre]

Thanks for checking @thomasriley. The issue I am trying to solve is this: I am using a wrapper cookbook to install Sensu, and set the version in a data bag. When I change the data bag to the latest Sensu version, sometimes it is too fast for the local yum cache to realise there are new packages, so chef will fail running on those machines. I believe setting this will fix this problem, but give me few more days to setup a kitchen test for the full cycle (I need to setup a yum repo with an older version, install Sensu with chef, copy the newer version, update data bag, and run chef again).

[majormoses]

I don't really know enough about the way yum does it's caching to provide much insight without some investigation. What you describe I am not sure if this is the right solution. Is there any reason you are managing the version in a databag rather than a cookbook? Let's open an issue to further discuss this.

To make this a backwards compatible change I would suggest adding a new attribute along the lines of default['sensu']['yum_flush_cache'] = nil and then modify the recipe to be flush_cache node['sensu']['yum_flush_cache'] unless node['sensu']['yum_flush_cache'].nil?. In your wrapper then you could set it to be something to what you want. Regardless of the actual solution I would be :+1: of adding that even if we find a better solution as it exposes options to people to do what they wish without having to force that on the whole community.

[majormoses]

@thomasriley is right in what that property does, here is the docs: https://docs.chef.io/resource_yum.html

Flush the in-memory cache before or after a Yum operation that installs, upgrades, or removes a package. Default value: [ :before, :after ]. The value may also be a Hash: ( { :before => true/false, :after => true/false } ).

Yum automatically synchronizes remote metadata to a local cache. The chef-client creates a copy of the local cache, and then stores it in-memory during the chef-client run. The in-memory cache allows packages to be installed during the chef-client run without the need to continue synchronizing the remote metadata to the local cache while the chef-client run is in-progress.

Agreed this is probably not what is not likely the best solution and certainly should not be the default.

[majormoses]

I am using a wrapper cookbook to install Sensu, and set the version in a data bag.

Databags are not versioned which is probably why you are seeing this problem, I'd move the attribute controlling sensu version into the wrapper cookbook or an environment cookbook. One of the reasons for this is that cookbooks are versioned and one of the first steps to a chef-client run is to pull down any new cookbooks. If the value changes while a chef-client is running it will continue to do what it set out to do during the compile phase and then on the next execution it will be re-evaluated and the new version of sensu will be installed as expected. Promoting a new version should work even if it installs the old, any other result would imply that better design choices would avoid the problem entirely. I am in an ubuntu shop but I know I have run this before at my last gig which was mixed and never ran into this.

[petre]

Thanks for the suggestion @majormoses. That makes sense, I don't want to impact the whole community with my changes. The best solution is to keep the version in the wrapper cookbook and update it when there is a new Sensu version, but due to the constraints of my Chef architecture it would be a time consuming process for me. That is why I moved the version to a data bag. BTW, I keep the data bag in a git repo, so it is versioned and I have a build job in Jenkins that pushed this to the Chef server.

[majormoses]

but due to the constraints of my Chef architecture it would be a time consuming process for me.

Ouch, not sure what that would be but I guess given whatever the constraints are this makes more sense. Your setup is clearly atypical which is why I suggested the best of both worlds. Allow you to proceed with a odd hack but not force everyone to use it. I will review shortly.

[majormoses]

released: https://supermarket.chef.io/cookbooks/sensu/versions/4.1.0