On Mar 22, 10:15 am, Andreas Paul <xorp...@googlemail.com> wrote:
> Is there a way to look up which nodes share that specific module or class?
No.
> # manifests/nodes.pp
> node 'serverA', 'serverB' {
> include puppet-tomcat::tomcatA
>
> }
>
> I need to access variables from both servers. E.g.
You need information pertaining to both servers, but that's not the
same thing.
> # worker.properties.erb
> <% for server in have_class_included('tomcatA') -%>
> JkWorkerProperty worker.<%= name %>.host=<%= server::ipaddress_eth0 %>
> <% end -%>
>
> which should result in two lines. One with the IP address of serverA and
> the other line with the IP address of serverB
>
> Currently I'm defining custom variables for each server:
> # manifests/nodes.pp
> if $fqdn == "serverA" {
> $ipA = 'localhost'
> $ipB = '222.222.222.222' }
> if $fqdn == "serverB" {
> $ipB = 'localhost'
> $ipA = '111.111.111.111' }
>
> and just hard code each worker
>
> # worker.properties.erb
> JkWorkerProperty worker.<%= name %>.host=<%= ipA %>
> JkWorkerProperty worker.<%= name %>.host=<%= ipB %>
>
> Which is just wrong, I know.
>
> Maybe there is another even simpler way to do it.
There are *better* ways to do it, but not necessarily *simpler* ones.
The key objective appears to be to use a data-driven approach in
constructing the desired worker.properties file. That's a good and
useful goal, and Puppet provides two main avenues to reach it:
1) Give the master all the needed data up front. That's sort of like
what you are now doing, but instead of individual variables you should
look into Puppet arrays and hashes. These can be iterated in your
template, hash values can be selected by key both in templates and in
Puppet DSL, etc.. The data structures themselves could be defined in
a data class somewhere, or else loaded via hiera for better data
abstraction (or both). Puppet's create_resources() function probably
gives you everything else you need to put this together.
2) Collect data from nodes. That involves defining resources
(probably of some defined type) that the nodes would export and the
master collect. A good target there might be file fragments of the
kind provided by the Puppet::Concat module.
Of the two, I would expect (1) to be lighter weight and more robust,
and no less general (the master has to have all the needed information
in some form, no matter what).
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
