On Tuesday, March 5, 2013 10:48:10 AM UTC-6, Schofield wrote:
>
>
> Not really a specific problem because obviously people are successfully
> using this pattern. I'm really trying to explore the difference between
> the different patterns and understand why you would chose one over the
> other. The current pattern that is working successfully for me is
> the role/profile pattern. Here I use a profile to associate a specific jdk
> version with the appserver version. It gives me one place to update the
> version of the jdk for all deployments of the app server. The problem that
> I can imagine (or rather what I don't fully understand yet) is how to
> manage the jdk version in hiera when the jdk version is dependent on the
> version of the app server and not facts on the node.
>
Much depends on the details, but if the JDK version required is a function
of the app server version, then the structure or arrangement of your hiera
data should reflect that. There are many ways to do it; here's one of them:
data
----
server_version_to_jdk_version:
1.0: 5.0
2.0: 6.0
2.5: 7.0
manifest
----
$server_to_jdk_table = hiera('server_version_to_jdk_version')
$jdk_version = $server_to_jdk_table[$appserver_version]
I think you can also define hierarchy levels based on %{} interpolated
variables that are not node facts, as long as they are in-scope at the
point where you perform the lookup. Depending on how your classes are set
up, you might also be able to make use of %{calling_class}.
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
