On Tuesday, November 18, 2014 6:21:33 AM UTC-6, Steven Post wrote:
>
>
>
> On Monday, November 17, 2014 4:06:02 PM UTC+1, jcbollinger wrote:
>>
>>
>>
>> On Monday, November 17, 2014 4:11:09 AM UTC-6, Steven Post wrote:
>>>
>>> Hi,
>>>
>>> I've been using puppet for over a year now, but now I have a problem,
>>> and I'm not seeing a solution.
>>> I have a hash to set up Java application servers in hiera, these get
>>> 'deeper' merged so we don't need duplicate declarations of every little
>>> option.
>>> Inside the manifest, the create_resources() function is called.
>>>
>>> Now the problem here is that one of the options inside the hash is an
>>> array of Java options, such as heap size, the garbage collector, the OOM
>>> behaviour, etc.
>>> Since arrays gets merged with hiera_hash in a 'deeper' merge, these
>>> options would be merged as wel.
>>> The heap and permsize are actually already separate options, so they
>>> don't have this problem, but if I set '-XX:NewRatio=2' and I wan't to
>>> override this for some nodes or clusters, I would set it as
>>> '-XX:NewRatio=3', but then this option is passed down twice, but with
>>> different values.
>>>
>>> How to solve this? Does anyone else have any experience to share about
>>> this?
>>>
>>>
>>
>> I'm not quite following. Perhaps a bit more detail about your data
>> structure would be helpful.
>>
>> If I were setting up an options hash then I would use option names as the
>> keys (e.g. 'XX:NewRatio') and option values as the values (e.g. 3). If you
>> were doing it that way, however, then you couldn't express different values
>> for the same option in your hash, so you couldn't have the same option
>> expressed twice.
>>
>>
>> John
>>
>>
>
> Hi,
>
> I've been thinking about this for a day now, I think I definitively need a
> hash, not an array here.
>
> An example of the outer hash, simplified for this example:
> jboss_application::app_version::jvm_defaults:
> additional_java_opts:
> - '-XX:+UseConcMarkSweepGC'
> - '-XX:NewRatio=2'
> - '-XX:+CMSClassUnloadingEnabled'
> - '-XX:OnOutOfMemoryError=''kill -9 %p'''
> - '-XX:+HeapDumpOnOutOfMemoryError'
>
> If you would change the array into a hash, how would you go about it?
>
I would do this:
additional_java_opts:
'-XX:+UseConcMarkSweepGC': null
'-XX:NewRatio': 2
'-XX:+CMSClassUnloadingEnabled': null
'-XX:OnOutOfMemoryError': 'kill -9 %p'
'-XX:+HeapDumpOnOutOfMemoryError': null
or perhaps this:
additional_java_opts:
'UseConcMarkSweepGC': true
'NewRatio': 2
'CMSClassUnloadingEnabled': true
'OnOutOfMemoryError': 'kill -9 %p'
'HeapDumpOnOutOfMemoryError': true
If the YAML parser doesn't recognize null as the primitive it is (in YAML
1.2) then perhaps it would be better to use an empty string instead, or
else use the second form. The other part of the equation is how those data
are *used*. Since you are at liberty to change the form of the data, you
must also be at liberty to change the template, resource type, or whatever
that consumes the data. Changes certainly will be needed there, and your
choice for the form of the data may be influenced by how you choose to
update their consumer.
> The 'NewRatio' for example is easy, since actually is key + value
> ('NewRatio' + '2'), a maximum heap size would be easy as well using 'Xmx'
> as a key.
> However the '+UseConcMarkSweepGC' or '+HeapDumpOnOutOfMemoryError' seem a
> bit trickier, especially if you want to disable the heapdump on certain
> nodes, or use a different GC algorithm (like GC1 for example).
> Also some options are related to eachother, such as the NewRation, which
> doesn't work when using an adaptive policy (different GC), or the
> 'CMSClassUnloadingenabled', which is not needed in conjunction with the
> default GC (parallel mark sweep).
> Perhaps I need to split the options in different variables?
>
>
There is a tension between flexibility and precision. What you have now,
or something related to it, is very flexible, but allows nonsensical
combinations of options to be specified. If you don't like that then you
don't have to do things that way, but to do otherwise will require more
complicated code.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/0d9f9d27-6b90-4576-b6d4-f108745ef30d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
