Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jakelandis opened this issue Feb 27, 2013 · 6 comments

Comments

Projects
None yet
2 participants
@jakelandis
Copy link

commented Feb 27, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 27, 2013

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 added a commit that referenced this issue Feb 27, 2013

[FIX] Fix incorrect attribute setting in `default.rb`
The default.rb attributes file used Chef 11 incompatible syntax for setting the node default attribute,
throwing the `Chef::Exceptions::ImmutableAttributeModification` exception.

See: http://www.opscode.com/blog/2013/02/05/chef-11-in-depth-attributes-changes/

Related: #68, #69
@karmi

This comment has been minimized.

Copy link
Member

commented Feb 27, 2013

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

@jakelandis

This comment has been minimized.

Copy link
Author

commented Feb 27, 2013

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

@karmi

This comment has been minimized.

Copy link
Member

commented Feb 27, 2013

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

@jakelandis

This comment has been minimized.

Copy link
Author

commented Feb 27, 2013

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

Sounds good. Closed.

@jakelandis jakelandis closed this Feb 27, 2013

@karmi

This comment has been minimized.

Copy link
Member

commented Feb 27, 2013

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.