For this one, have a look at chef_rewind (sorry for the link I'm on the phone), the idea is to replace the server.xml.erb from the tomcat cookbook by your own (one in your wrapper cookbook templates dir), with the correct replacement done in the Erb, starting from the original one to make your own is a good path usually.
Le 11 déc. 2014 18:50, Douglas Garstang <doug.garstang@gmail.com> a écrit :
Tensibai,And now for my next trick, err issue.
I'm looking at our current server.xml in tomcat, which is created from a whole bunch of grepping and sedding and the like. It manipulates things that the tomcat cookbook has no control over. For example it disables the APR stuff.
How on earth.....? If I override the wrapped server.xml with rewrite in the top level cookbook, then none of the variables that it expects are going to be passed in, and it's going to fail.
Doug.
On Thu, Dec 11, 2014 at 9:38 AM, Tensibai <tensibai@iabis.net> wrote:
Le 2014-12-11 18:12, Douglas Garstang a écrit :
Further to this, I could put the setting:For thoose edge cases, you may use include_attributes to reload the attribute file you know need it.But as far as you tell it, just do a node['tomcat']['java_options'] += " -Xms#{jvm_heap_min}M -Xmx#{jvm_heap_max}M -Djava.awt.headless=true" in your recipe should do...If you really have to use node.override (which I highly doubt a simple node['attr'] should do) or wish to set in the recipe the value and then reload the atrtibute file the idea would be to do something like:in the attribute file: [..sliced..] default['tomcat']['java_options'] += " -Dcom.sun.management.jmxremote.ssl=false" default['tomcat']['java_options'] += node['slice-tomcat']['java_tier_options'] if node.include?('slice-tomcat') && node['slice-tomcat'].include?('java_tier_option') the if is evaluated left to right, if the first is false, it will stop there and not raise a no method exception for [] on nil class on the second one then in your recipe node['slice-tomcat']['java_tier_options'] += " -Xms#{jvm_heap_min}M -Xmx#{jvm_heap_max}M -Djava.awt.headless=true" include_attribute 'slice-tomcat' But generally if you have to set attributes in the recipe, you're doing something the wrong way somewhere.You may have a better time namescoping by instance type,then you may copy the correct namespaced attributes into the target one instead of conditionnaly adding parameters. (you'll still do something like node['tomcat']['java_options'] = node['intance_type']['java-options'] at the end, but it sounds less hard to maintain in time)I'm perhaps not really clear, feel free to tell and I'll try to write something more structured :)node.override['slice-tomcat']['java_tier_options'] =
in the top level cookbook's attributes file. Presumably then, when it includes the next one in the stack, the value would be set and all would be ok. However, the value of this setting itself is calculated from the instance type. This means I can't put this in the attributes file. It has to go in the recipe. Therefore, if it has to go in the recipe of the top level cookbook, it also has to go in the recipe of the included cookbook. Now we're being forced to avoid usage of the attributes files and we have a big mess.
Doug.
On Thu, Dec 11, 2014 at 9:03 AM, Douglas Garstang <doug.garstang@gmail.com> wrote:
Ah yes, the dreaded two phase compile thing that forces you to modify your code to operate in a way that makes not much sense.I'm already seeing this. My top level tomcat application cookbook set an attribute:
node.override['slice-tomcat']['java_tier_options'] = " -Xms#{jvm_heap_min}M -Xmx#{jvm_heap_max}M -Djava.awt.headless=true"
In it's recipe, it then included the slice-tomcat (wrapper for tomcat) recipe, and in it's attributes file it has:
default['tomcat']['java_options'] = "${JAVA_OPTS} -Dcom.sun.management.jmxremote"
default['tomcat']['java_options'] += " -Dcom.sun.management.jmxremote.port=9010"
default['tomcat']['java_options'] += " -Dcom.sun.management.jmxremote.rmi.port=9010"
default['tomcat']['java_options'] += " -Dcom.sun.management.jmxremote.authenticate=false"
default['tomcat']['java_options'] += " -Dcom.sun.management.jmxremote.ssl=false"
default['tomcat']['java_options'] += node['slice-tomcat']['java_tier_options']
which fails because node['slice-tomcat']['java_tier_options'] isn't set, presumably because it's operating only on attributes, and since ['slice-tomcat']['java_tier_options'] is set in a recipe, it hasn't been set yet.
Well, I might as well just do away with attributes files all together then. Why bother? I'm now forced into putting attributes into recipes, which probably isn't the right way, but what is the alternative?
Doug.
On Thu, Dec 11, 2014 at 12:47 AM, Tensibai <tensibai@iabis.net> wrote:
Le 2014-12-11 00:10, Douglas Garstang a écrit :
Well, this is weird.Someone else replied before Eric and now that reply has disappeared. His suggestion, well I was going to follow it, and it's gone poof. Where did it go?
I'm confused. The java cookbook in one place says if you want the oracle java to include the 'oracle' recipe. Further down, it says to use attributes. Which is it?
It's also not clear now, and never has been, if setting default['java']['install_flavor'] = 'oracle' in my wrapper cookbook will have an effect on a cookbook two levels away in the stack. Ie if I have A -> B -> C and cookbook A has default['java']['install_flavor'] = 'oracle'... will that affect how cookbook B operates?
Doug.
To answer on the 2 levels away: yes.
I'll try to give an exemple:
Cookbook A depends on cookbook B wich in turns edpends on cookbook C.
Chef run will load attributes (which is a common hash for all cookbooks) from C then B then A, so values in A will override thoose in C.
After that the recipe will be compiled.
For the Java cookbook it will do (from default.rb):
include_recipe "java::#{node['java']['install_flavor']}"So it will include the correct recipe from the attribute value.
Once the compilation is done, chef will enter the converge phase and act on resources, setting them in the desired state (downloading jave, etc)
Hope it helps understanding how it works
More details on the chef run phases here: http://docs.chef.io/chef_client.html#the-chef-client-title-run
One of the ticket about this ordering is solved by https://github.com/opscode/chef/pull/508 I can't find doc or a blog post about how the run_list is expanded
On Wed, Dec 10, 2014 at 1:06 PM, Eric Helgeson <erichelgeson@gmail.com> wrote:
Yep, you can, take a look at the examples in the readme - https://github.com/agileorbit-cookbooks/java/#examplesJust override some attributes and it will install that version.Also be sure to mirror the oracle binary locally in production, as downloading directly can be troublesome at times https://github.com/agileorbit-cookbooks/java#production-deployment-with-oracle-java-Eric
On Wed Dec 10 2014 at 2:32:05 PM Douglas Garstang <doug.garstang@gmail.com> wrote:
I was taking a look at the tomcat cookbook for chef, https://github.com/opscode-cookbooks/tomcat.It installs the OpenJDK. It doesn't seem to have a facility to change that to the Oracle JDK. I look a look inside the tomcat recipe and yep, it's got:
include_recipe "java"
The java cookbook can install the Oracle JDK, but the defaut installs the OpenJDK. Is there a way I can override this without modifying the java or tomcat cookbooks?
Doug
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
