Puppet users - Mar 2012 - lookup node variables from different nodes

Is there a way to look up which nodes share that specific module or class?

# manifests/nodes.pp
node ''serverA'', ''serverB'' {
      include puppet-tomcat::tomcatA
}

I need to access variables from both servers. E.g.

# 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.

Best regards,
Andreas Paul

-- 
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/-/95YGM2IgT9gJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.