0

I have a service implemented in Java which depends on 3 property files. I have defined 'define' for each of the property file in a common properties module and consuming them from service specific module. The 'define' for one of the property file is shown below:

define properties::rabbitmq (
  $property_file,
  $service_name,
  $rabbitmq_host,
  $rabbitmq_username,
  $rabbitmq_password,
  $rabbitmq_port,
  $rabbitmq_vhost) {
  file { $property_file:
    ensure  => file,
    content => template('config/rabbitmq.properties.erb'),
    mode    => '0644',
    notify  => Service[$service_name],
  }
}

I am following roles and profile pattern in my puppet code and doing all hiera lookups in service specific profile. Now because of this whenever there is a change in property files, I need to make cascading changes to all of my puppet modules that consumes that property file. The changes are needed in profile (hiera lookup), module init.pp (addition/removal of parametes from constructor) and config.pp (parameter adjustment when invoking 'define' for a property file).

I feel that the above problem can be solved by incorporating hiera lookups in 'define' for a property file, like this:

define properties::rabbitmq ($property_file, $service_name,) {

  $rabbitmq_host = hiera('rabbitmq_host')
  $rabbitmq_username = hiera('rabbitmq_username')
  $rabbitmq_password = hiera('rabbitmq_password')
  $rabbitmq_port = hiera('rabbitmq_port')
  $rabbitmq_vhost = hiera('rabbitmq_vhost')

  file { $property_file:
    ensure  => file,
    content => template('config/rabbitmq.properties.erb'),
    mode    => '0644',
    notify  => Service[$service_name],
  }
}

But, above is a violation of roles and profile pattern. The above is doing hiera lookup in a module instead of doing it in profile. Now, the module has a tight dependency on hiera. It being an internal module (not meant for puppet forge), I guess, it should be OK to violate the guideline in favor of code maintainability.

I seek opinion from others on above.

Anand Patel
  • 6,031
  • 11
  • 48
  • 67
  • 2
    Consider mixing the code above. Use hiera lookups in 'defines' as a default parameter values e.g `define properties::rabbitmq ($rabbitmq_host = hiera('rabbitmq_host') , ...) ` – kkamil Jan 20 '15 at 10:17
  • I would do it exactly the way you do it and wouldn't worry about convention. This is the price you pay for having a general module like properties. – Mateusz M. Jan 27 '15 at 16:13
  • The design pattern looks a little hodge-podge, if you pardon me saying so. The nature of the `properties` module is unclear to me, and it uses a template from a `config` module, further complicating things. I believe that roles/profiles works best if each of your modules is self-contained. The RabbitMQ properties should be defined by your `rabbitmq` module, and not be used by other modules. Without a broader look at your code base, I cannot comment on how feasible or not such an approach would be for you. All that aside, using `hiera()` liberally in private modules is fine imho. – Felix Frank Feb 12 '15 at 19:04

0 Answers0