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

using tomcat7 doesn't honor default attributes #89

Closed
jolexa opened this issue Aug 5, 2014 · 5 comments
Closed

using tomcat7 doesn't honor default attributes #89

jolexa opened this issue Aug 5, 2014 · 5 comments

Comments

@jolexa
Copy link

jolexa commented Aug 5, 2014

When setting "node.default['tomcat']['base_version'] = 7" - you must also set all of the attrs in attributes/default.rb again in your recipe/env in order for /etc/sysconfig/tomcat7 to be created corrected. If you do not, there is a config file set for tomcat6 settings placed in /etc/sysconfig/tomcat7 which is odd. I don't understand the multi instance stuff enough to provide a fix

@rhass-r7
Copy link

rhass-r7 commented Aug 5, 2014

This is a known issue with Chef: (https://tickets.opscode.com/browse/CHEF-4234)

The issue has a workaround which will allow you to hack around the bug in Chef, presumably until this issue is resolved in Chef 12.

Eg:

node.force_default['tomcat']['base_version'] = '7'
node.from_file(run_context.resolve_attribute(*parse_attribute_file_spec('tomcat')))

@jolexa
Copy link
Author

jolexa commented Aug 5, 2014

Ah, thanks. I thought it was a bug in the cookbook because the issue only
surfaced when I changed from tomcat 6 to 7.

On Tue, Aug 5, 2014 at 12:38 PM, Ryan Hass notifications@github.com wrote:

This is a known issue with Chef: (
https://tickets.opscode.com/browse/CHEF-4234)

The issue has a workaround which will allow you to hack around the bug in
Chef, presumably until this issue is resolved in Chef 12.


Reply to this email directly or view it on GitHub
#89 (comment)
.

@rhass-r7
Copy link

rhass-r7 commented Aug 5, 2014

In some respects, it is a bug in the cookbook as well, however it is not a new one. The use attributes in attribute values is actually the cause of the issue at the cookbook level. It works fine when the cookbook is not being wrapped, but completely breaks down in a wrapper cookbook as you have found.

Nevertheless, resolving this issue is a substantial refactor as the way in which different versions are defined would need to be redone entirely. I would love to see it fixed in both Chef itself and this cookbook. This said, will leave it to the maintainer to decide if they want to keep this issue open for a refactor or not.

gsaslis pushed a commit to gsaslis/tomcat that referenced this issue Oct 12, 2015
There are several issues that stem from this very root cause: sous-chefs#89, sous-chefs#102, sous-chefs#129, sous-chefs#148 and sous-chefs#174. I've moved all derived attributes into a helper method that gets evaluated at recipe run time, so that the overriden values are taken into account, regardless of how they've been overriden (even from another cookbook's attributes).
tl;dr
# Any cookbook attribute that uses the value of another attribute to calculate its own value (derived)
# should be included in the new libraries/helper method, so that the calculation of the value takes place at runtime of the recipe.
# The reason is simple: Due to how attribute precedence works in Chef, when an attribute is overriden, it is not always
# the case that the derived attributes will use the correct value of the original attribute to calculate their own.
# This depends on how the attribute has been overriden (cookbook attributes, role, environment, etc.)
# See [this](https://christinemdraper.wordpress.com/2014/10/06/avoiding-the-possible-pitfalls-of-derived-attributes/) for a detailed explanation.
gsaslis pushed a commit to gsaslis/tomcat that referenced this issue Oct 12, 2015
There are several issues that stem from this very root cause: sous-chefs#89, sous-chefs#102, sous-chefs#129, sous-chefs#148 and sous-chefs#174. I've moved all derived attributes into a helper method that gets evaluated at recipe run time, so that the overriden values are taken into account, regardless of how they've been overriden (even from another cookbook's attributes).
tl;dr
# Any cookbook attribute that uses the value of another attribute to calculate its own value (derived)
# should be included in the new libraries/helper method, so that the calculation of the value takes place at runtime of the recipe.
# The reason is simple: Due to how attribute precedence works in Chef, when an attribute is overriden, it is not always
# the case that the derived attributes will use the correct value of the original attribute to calculate their own.
# This depends on how the attribute has been overriden (cookbook attributes, role, environment, etc.)
# See [this](https://christinemdraper.wordpress.com/2014/10/06/avoiding-the-possible-pitfalls-of-derived-attributes/) for a detailed explanation.
@tas50
Copy link
Contributor

tas50 commented Feb 25, 2016

First off I'm very sorry that it's taken so long to get back to you on this issue. For a significant period of time there was no active Chef Software Inc. maintainer for this repository and things languished. We're now actively maintaining this cookbook again, and as part of that I've rewritten the cookbook with new custom resources for installing Tomcat from Apache Org sources. This will ship in an upcoming 2.0 release and then we'll remove the existing recipes and providers in a future 3.X release. With those new providers I believe the need for this change goes away so I'm going to close this out. I encourage you to give the new providers a try and let me know if we can tackle more Tomcat management without the attributes bloat the current code suffers from. They're on the master branch and once the documentation and testing improves a bit they'll be released as a 2.0 cookbook.

@tas50 tas50 closed this as completed Feb 25, 2016
@lock
Copy link

lock bot commented May 5, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators May 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants