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?

1
  • 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/… May 8, 2014 at 20:48

1 Answer 1

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

4
  • 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/… May 8, 2014 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. May 8, 2014 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?
    – ek9
    May 9, 2014 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. May 9, 2014 at 15:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .