Home / server / Questions / 639356
In Process
mc0e
Asked: 2014-10-25 02:37:31 +0800 CST

puppetlabs-postgresql: how to set globals properly without duplicate definitions

  • 772

puppetlabs-postgresql's documentation recommends setting values in postgresql::globals like so:

class { 'postgresql::globals':
  encoding => 'UTF8',
  locale   => 'en_NG',
}->
class { 'postgresql::server':
}

However, this doesn't work:

class { 'postgresql::client: }
class { 'postgresql::globals':
  encoding => 'UTF8',
  locale   => 'en_NG',
}->
class { 'postgresql::server':
}

Because postgresql::client inherits from postgresql::parameters, which inherits from postgresql::globals. So when it gets to the explicit instantiation of the postgresql::globals class, it complains about a duplicate definition.

changing the order, it does work:

class { 'postgresql::globals':
  encoding => 'UTF8',
  locale   => 'en_NG',
}->
class { 'postgresql::server':
}
class { 'postgresql::client: }

However, in real use, my instantiation of postgresql::client and postgresql::server are in different classes associated with server classes I use, and I really don't want to be creating a required ordering for those classes. Also, I want the globals definitions to apply to postgresql::client even on servers which do not run postgresql::server.

If we were using puppet 3.x, I'd define the required globals values in hiera, but we're still on puppet 2.7.

Is there a way to fix this without modifying the puppetlabs distribution? I'm currently thinking this may warrant a bug report to puppetlabs, but still wonder if I'm just missing a simple solution.

EDIT: having read @FelixFrank's input, I've created a bug report at https://tickets.puppetlabs.com/browse/MODULES-1466.

puppet

1 Answers

  1. Yes, Hiera would be the best solution. Note that you can (and should) add Hiera to Pupet 2.7.x in plugin form.

    Barring that, your options are limited. The require relationship between any two classes will not have an effect. On the contrary, observe that the following refactoring of your working manifest does yield your error as well:

    class { 'postgresql::server': }
<-
class { 'postgresql::globals':
    encoding => 'UTF8',
    locale   => 'en_NG',
}

    The reason is that the issue is based on parse order or evaluation order - the order in which the manifest compiler encounters the class declarations. The require/before parameters (and chaining arrows) only add relationships to the catalog being built, for consumption by the puppet agent.

    Basically, you would have to ensure that your own PostgreSQL server class is always evaluated before the client class, e.g.

    role::posgre_server_with_client {
    include profiles::postgre_server
    include profiles::postgre_client
}

    Such ordering cannot always be guaranteed in complex manifests (that might include especially the client functionality from numerous contexts). As such, I think there is a strong case for declaring this a bug in the module. Since the patterns that lead to the problem are rather pervasive (I think), there might be cause to question current module design practice in general.

    I will see about gathering some more opinions from the community about this.

    • 1