When updating versions, the wrong version can be installed unless you manually clear node attributes (chef server only)

[jakelandis]

When updating versions, the wrong version can be installed unless you manually clear node attributes (chef server only).

Scenario:
Running a chef client node installed elasticsearch 0.20.1, then update the elasticsearch/settings to version 0.20.4 (a non-default version), then run chef-client. The standard out log will appear to install 0.20.4, but in reality it downloads 0.20.1 (the original version) and places version 0.20.1 in /usr/local/elasticsearch-0.20.4.

This is occurring because the node attributes are stale from prior runs. Looking at the node attributes on the chef server, the "version" is updated as it should be, but "filename" and "download_url" are stale (from a prior configuration).

The work around is easy...manually delete the node/elasticsearch attributes prior to updating, but this should not be necessary.

[karmi]

Hi, there's been a report like that in #61. I usually test the cookbook with Chef Solo in Vagrant and EC2, and don't have any streamlined workflow for Chef server -- looks like it's really needed.

My bet here is that Chef is failing to update attributes properly somehow. Could you run Chef with the debug or put require 'pry'; binding.pry and manually verify the download_url and other attributes? Also notice the fixed Chef behaviour in the 11 version [#68]

[karmi]

See the info in #68, verified to work correctly on Chef 11.

[jakelandis]

I was able to verify the latest code + chef 11 (client) resolves this issue. See #68 for details.

[karmi]

So let's close this and continue in #68?

[jakelandis]

So let's close this and continue in #68?

Sounds good. Closed.

[karmi]

Extensively tested in Chef Solo and Chef Server in both Vagrant and EC2 machines, it should behave properly now with attributes set either in data bag, role, environment or directly on the node. Could you verify it, please?