Thank you for your answer!
I chose the following solution:
# add the IPs of the workers in a dedicated array
$worker = [ '123.456.678.900', '123.456.678.901' ]
# give the apache config class this array
puppet-apache-tomcat::cfg { "tc6_foobar":
vhostname => 'test-foobar6',
worker => $worker,
portrange => 118,
prodlevel => 3,
wwwdir => '/tmp/foobar6.foo.bar',
}
This then uses the following template:
<% worker.each do |w| -%>
<% if w != ipaddress_eth0 -%>
JkWorkerProperty worker.<%= workername %>.host=<%= w %>
<% else -%>
JkWorkerProperty worker.<%= workername %>.host=localhost
<% end -%>
JkWorkerProperty worker.<%= workername %>.port=<%= portrange %>09
<% end -%>
So now I have to edit 2 files, when I want to add another tomcat server to
the worker list. I thought there was a better/simpler way to do this.
On Friday, March 23, 2012 2:05:51 PM UTC+1, jcbollinger wrote:
>
>
>
> 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 view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/xng3IfIoxC0J.
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.
