Multiple puppet resources which share a single config file

Question

I'm developing a custom puppet module for managing JBoss Application Servers. I consider each application deployed on the appserver as a self-contained resource. But some of the applications need dedicated config changes in JBoss' configuration file.

Each application is a puppet resource as well but most of the applications do not know each other.

At the moment I perform changes on JBoss' configuration file using augeas. That works even if many resources require changes on that config file but it is very complicated, error prone, and slow.

Actually I want to use templating for the config file but the question is how I can aggregate all required artifacts coming from different (sub-)modules before triggering the templating mechanism without having to know how man config artifacts there are?

Example:

define jboss_config($config) {
  # do something with the config
}

jboss_config {
  config => 'some configuration for app 1'
}
jboss_config {
  config => 'some configuration for app 2'
}    
jboss_config {
  config => 'some configuration for app 3'
}    
jboss_config {
  config => 'some configuration for app 4'
}    
jboss_config {
  config => 'some configuration for app 5'
}

#now, as all calls to "jboss_config" are done, 
#perform templating of the configuration file.

How can I define a dependency that triggers the templating once after all calls of "jboss_config" are done? Notify doesn't seem to work because it would trigger templating after each configuration step.

Answer 1

My go-to approach for things like this is to use the concat module, which will handle all of the notifications for building the config file itself, and wrap it in application-specific resource definitions. What I mean by that last part is something like this:

class jboss {
  concat { '/path/to/jboss/config/file':
    owner => 'whoever',
    group => 'whoever',
    mode  => 'whatever',
  }
  concat::fragment { 'jboss header':
    target  => '/path/to/jboss/config/file',
    content => template('jboss/config.header.erb'),
    order   => 00,
  }
  concat::fragment { 'jboss footer':
    target  => '/path/to/jboss/config/file',
    content => template('jboss/config.footer.erb'),
    order   => 99,
  }
}
define jboss_config ($config) {
  concat::fragment { "jboss config ${title}":
    target  => '/path/to/jboss/config/file',
    content => template('jboss/config.item.erb'),
    # Alternately, if your needs are simple enough:
    #content => "${config}\n",
  }
}

Because you're wrapping the file concatenation, the client modules don't have to know about the exact mechanism you're using for the configuration, and you can add parameters to the resource as needed for describing it in a natural way (i.e. not having to write strings that match the config file syntax, but specifying only the necessary configuration data.)