/opt/chef/version-manifest.txt doesn't have proper version on line one, causing extra installations via Omnibus

[NickLaMuro]

So here is by setup:

.kitchen.yml

---
driver:
  name: vagrant
  require_chef_omnibus: "11.10.4"

provisioner:
  name: chef_solo

platforms:
  - name: centos-7.1

suites:
  - name: default
    run_list:
      - recipe[foo]
    attributes: {}

The issue

When test-kitchen downloads chef via omnibus, here is the /opt/chef/version-manifest.txt that is generated:

[vagrant@default-centos-71 ~]$ cat /opt/chef/version-manifest.txt
chef 11.6.0-109-ga3d5161

Component          Installed Version                          Version GUID
-------------------------------------------------------------------------------------------------------------
bundler            1.1.5
cacerts            2014.01.28                                 md5:5d108f8ab86afacc6663aafca8604dd3
chef               0d097217dda26ac5551d1ad24132d9e53a62e0fb   git:0d097217dda26ac5551d1ad24132d9e53a62e0fb
libedit            20120601-3.0                               md5:e50f6a7afb4de00c81650f7b1a0f5aea
libgcc             11.10.4
libiconv           1.14                                       md5:e34509b1623cec449dfeb73d7ce9c6c6
libyaml            0.1.5                                      md5:24f6093c1e840ca5df2eb09291a1dbf1
ncurses            5.9                                        md5:8cb9c412e5f2d96bc6f459aa8c6282a1
openssl            1.0.1f                                     md5:f26b09c028a0541cab33da697d522b25
preparation        11.10.4
ruby               1.9.3-p484                                 md5:8ac0dee72fe12d75c8b2d0ef5d0c2968
rubygems           1.8.24                                     md5:3a555b9d579f6a1a1e110628f5110c6b
version-manifest   11.10.4
yajl               1.1.0
zlib               1.2.6                                      md5:618e944d7c7cd6521551e30b32322f4a

Based on the code here, this will read the first line in that file and it will not match the requested version, and re-install on subsequent runs.

Seems to be a glitch with the generated version-manifest for that version, and my guess is based on how old it is, it would be in a won't fix state.

Obviously, partial versions wouldn't even work here because it is returning a completely bogus version number, unless I were to drop down to just chef 11, which isn't really ideal in my case.

Suggestion

Curious if the following code change would be acceptable as a work around since we can't seem to trust the /opt/chef/version-manifest.txt based on the above information:

if $1/bin/chef-solo -v > /dev/null 2>&1; then
  chef_version="`${1}/bin/chef-solo -v | cut -d \" \" -f 2`";
elif test -f "${1}/version-manifest.txt"; then
  chef_version="`head -n 1 ${1}/version-manifest.txt | cut -d \" \" -f 2`";
else
  chef_version="Not Found"
fi

That said, this is only a minor annoyance, so if there is a strict reason that we are using the version-manifest.txt before the bin, that is fine, and I will "deal with it" accordingly. That said, this might be related to some of the issues that have been already brought up:

• require_chef_omnibus re-installs chef-client when not needed #691
• run with specific version of the chef-client #715

P.S. Thanks for the great tool!

[NickLaMuro]

So, after looking at this further, it seems like these has been worked on recently to add checking the version-manifest.txt first...

#788

So now I am not sure which is the correct course of action for this...

[NickLaMuro]

After cloning this to attempt a solution, I found out that it is in the works to include the https://github.com/chef/mixlib-install to handle the work for the current scripts. I will work this out on that repository and close this PR. Thanks!