-
-
Notifications
You must be signed in to change notification settings - Fork 387
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
Comments
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'))) |
Ah, thanks. I thought it was a bug in the cookbook because the issue only On Tue, Aug 5, 2014 at 12:38 PM, Ryan Hass notifications@github.com wrote:
|
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. |
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.
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.
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. |
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. |
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
The text was updated successfully, but these errors were encountered: