Case 1:  if you keep your data elsewhere you can use extlookup or Hiera to
retrieve it as needed.

Case 2:  you may want to look at concat,  it's tailor made for this
scenario.
On Aug 3, 2011 6:45 PM, "hsanson" <hsan...@gmail.com> wrote:
> I have a huge library of custom classes/defines for all my servers and
> I consider myself fluent in puppet DSL. Still there are some
> situations I still find hard to handle and was wondering if someone
> can help me find a better way to handle these:
>
> Case 1: One define/class requires knowledge of another class in the
> same node
>
> Suppose we have a amanda_dir define and a zabbix_agent class. The
> amanda_dir
> defines a amanda directory for backup on the node and the
> zabbix_agent class
> installs and configures basic zabbix monitoring on the node.
>
> My current configuration allows me to add a zabbix_server variable
> to the amanda_dir
> define. If this variable is set then the backup is set in a way so
> it reports to the zabbix
> server if the backup was successful or send alarm is an error
> occurred.
>
> define amanda_dir($path, $zabbix_server = "") {
> ....
> }
>
> class zabbix_agent($server) {
> ....
> }
>
> node my_node {
> class { "zabbix_agent": server => "10.13.1.1" }
> amanda_dir { "/etc":
> zabbix_enable => true,
> zabbix_server => "10.13.1.1"
> }
> }
>
> As you see there is duplicated information in the node definition
> (the zabbix server IP).
> Ideally the amanda_dir define should be able to determine if the
> zabbix_agent class is included in
> the same node and be able to find the zabbix server value and
> configure itself to send backup status
> reports to the configured zabbix server without need to replicate
> server information or relying on node
> scoped variables or exported resources:
>
> define amanda_dir($path) {
> if defined(Class["zabbix_agent"]) {
> $zabbix_server = Class["zabbix_agent::server"]
> .....
> }
> }
>
> this way the amanda_dir define does not require the additional
> zabbix_server to be set explicitly.
>
> This is the simplest example I have but I have several other
> situations were a define/class can
> greatly benefit from the ability to query information from another
> included classes in the same node.
> The most common one is installing certain versions of packages
> depending on previous installed
> versions of libraries (e.g. Nginx+Passenger package version depends
> on Ruby package version).
>
> Case 2: Two or more defines/classes need to modify the same file:
>
> I have a openvpn_tunnel define that creates a openvpn server
> configuration file at
> /etc/openvpn/$name-server.conf. Also I have a openvpn_route define
> that allows me
> to configure routes to be pushed to the openvpn clients when they
> connect. The problem
> is that the routes information has to be added to the corresponding
> tunnel configuration file
> /etc/openvpn/$name-server.conf.
>
> So the situation is that every time puppet runs in the node the
> openvpn_tunnel define creates
> the server configuration file and the openvpn_route define modifies
> this file adding the desired
> route. The next time puppet runs the openvpn_tunnel define will see
> the conf file has been
> modified so it recreates it (deleting the added routes) and then the
> openvpn_tunnel define will
> see the routes removed and add them again. This creates an infinite
> loop that never ends.
>
> Case 3: File transfer between nodes
>
> Some cases certain generated files in one node need to be available
> on other nodes (e.g. ssh keys,
> ssl certs, etc.). Current solution is pre-generate these and then
> distribute them via the puppet fileserver
> but sometimes I require the file to be generated dynamically at the
> specific node because it requires local
> information that may change with time (e.g. DHCP assigned IPs).
>
> --
> 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.
>

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

Reply via email to