Package install is never up to date

[ghost]

Expected Behavior

Kitchen converge on subsequent runs should have no resources changed

Current Behavior

On subsequent runs the package for sensu keeps getting installed, as a result it triggers a service restart.

Possible Solution

Basically the issue appears to be in the epoch version. if I do a yum info of sensu I get
Name : sensu Arch : x86_64 Epoch : 1 Version : 1.5.0 Release : 1.el7 Size : 82 M Repo : installed From repo : sensu Summary : A monitoring framework that aims to be simple, malleable, and scalable. URL : https://sensu.io License : MIT Description : A monitoring framework that aims to be simple, malleable, and scalable.

and if I in my cookbook a simple
package 'sensu' do version '1:1.5.0-1.el7' end
Everything works as expected. But using the attribute
default["sensu"]["version"] = '1:1.5.0-1'
I get an error
FATAL: ArgumentError: Malformed version number string 1:1.5.0
if I use
default["sensu"]["version"] = '1.5.0-1'
The package just gets installed at every run of chef and triggers a restart of the service
Looks like were doing a lazy against the helper to join the version together in the helper. so I wonder if there is either an issue in sending the ':' to the helper, which seems fine and just does a join anyway or something else?

Steps to Reproduce (for bugs)

1. kitchen converge with a wrapper on centos 7
2. set your version attribute to '1.5.0-1.'
   3.kitchen converge first time things look good
   4.kitchen converge a second time and package is set to install again, triggering a restart of he service

Context

Right now im trying to get he cookbook working before putting this up into the environment

Your Environment

• Version of this cookbook used: 'sensu', '= 5.4.0'
• Version of Sensu used: 1.5.0-1
• Version of Chef used: 14.5.33
• Operating System and version (e.g. CentOS 7, Ubuntu 14.04): Centos 7

[majormoses]

Hmm I don't recall seeing this with ubuntu I think you need to configure both of these attributes because epel versioning as of centos7: https://github.com/sensu/sensu-chef/blob/v5.4.0/attributes/default.rb#L20-L21 Let me know if that works if not I can try to dig into it a bit.

[ghost]

Hmm I don't recall seeing this with ubuntu I think you need to configure both of these attributes because epel versioning as of centos7: https://github.com/sensu/sensu-chef/blob/v5.4.0/attributes/default.rb#L20-L21 Let me know if that works if not I can try to dig into it a bit.

Thanks for the reply. This is actually to do with the epoch value not the platform value.
default["sensu"]["version_suffix"] looks like el7 is whats getting tagged as in
suffix = suffix_override || ".el#{platform_major}"

what I'm needing or at least running into is its wanting the affix which is what epoch is. At least thats what I can see.

[majormoses]

I will try to look into this sometime this week but I am on-call so I can't guarantee I will find much time until the weekend. Can you verify if the debian based distros also exhibit this issue?

[ghost]

Apologies got a little busy with some things at work. Yes I will most likely have some time in the morning to delve a little into this. On a side note speaking of denian looks like this has been addressed to #517
Then looking at the code for how a debian package is installed it does a simple
package "sensu" do version node["sensu"]["version"] options package_options notifies :create, "ruby_block[sensu_service_trigger]" end

Which actually supports what I noticed when adding epoch.
Where redhat a helper library gets called which isnt to crazy but with the lazy enumeration I think thats where having a colon gets messed up.

I will need to test tho if not including epoch will suffice a package already being up to date in debian.

[majormoses]

@xxwassyxx just checking if you had time to get around to this