2

I am not sure how to word this questions so please suggest an edit if you feels its inappropriate.

I am trying to extend existing puppet modules with support of different OS. I have ran out into a small problem which I am not sure how I could solve in an elegant way. In params.pp file there is such definition of OS-specific packages to install:

case $::osfamily {
  'RedHat': {
    $package_server = 'mariadb-server'
    $package_client = 'mariadb'
    $php_package_name = 'php-mysql'
  }
...

The module is written in such way that whole configuration depends on having $php_package_name installed. I want to exnted this module for different OS, which does not have a separate mysql package for php, thus I set $php_package_name variable to undef. This brings a problem, that puppet tries to install Package[undef].

What would be a good way to prevent it? My thoughts so far war setting it to false and have whole definition of $php_package_name fire only if $php_package_name != false. Maybe there is a better way?

  • Setting the $php_package_name to false is a solution, that will work 50% of time. The other 50% times you will have the if $php_package_name != false evaluated first, and $php_package_name = false only later: unfortunately Puppet doesn't use the information where a variable is defined and where it is used to do a correct variable definitons' parsing. See: serverfault.com/questions/590762/… – Adam Ryczkowski May 8 '14 at 20:48
3

Yup, that seems like a reasonable approach. I'd suggest a slight variation on that, add a new param which determines whether the package resource which uses $php_package_name should be applied at all:

case $::osfamily {
  'RedHat': {
    $package_server = 'mariadb-server'
    $package_client = 'mariadb'
    $php_package_name = 'php-mysql'
    $php_package_install = true
  }
  'otherOS': {
    $package_server = 'mariadb-server'
    $package_client = 'mariadb'
    $php_package_install = false
  }
  ...

Then where the resource is:

if $thismodule::params::php_package_install {
  package { $thismodule::params::php_package_name:
    ensure => present,
    ...
  }
}

Keep in mind that the method of doing all of your OS-specific stuff in params.pp might not end up being cleaner if the resources needed for the install on the new OS are wildly different; that might just turn your manifest file into an unreadable rat's nest of conditions and parameters. In that case, don't be afraid to just split the different OS off into a separate class (such as install_el.pp for the RedHat family and install_otheros.pp for the new family, with the correct one being included from init.pp or params.pp).

| improve this answer | |
  • Are you sure it will work 100% of times? I am not sure one can rely on the order in which the variables are parsed. See: serverfault.com/questions/590762/… – Adam Ryczkowski May 8 '14 at 20:53
  • @AdamRyczkowski Yeah - the module he's modifying (and my recommendation to change it) is using the "params pattern", which relies on class inheritance to ensure correct evaluation order. – Shane Madden May 8 '14 at 21:00
  • Thanks, this mostly answers my question. By the way, I already have $php_package_ensure = 'present', can I just check that or do you suggest also having $php_package_install? – phoops May 9 '14 at 7:02
  • @edvinas.me Up to you - in my opinion it's clearer what's going on with a separate variable, but if nobody but you will be using this module then that's probably not a concern. – Shane Madden May 9 '14 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.