Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to install the PuppetDB Module. Part of this bundles a module for installing some requisite Postgres instances which I am using as well.

We primary use heira to configure roles and set various properties.

I have the configuration far enough long that if I add

roles:
    - role::postgresql_puppetdb

To a hostnames hiera yaml file it will get picked up and get a basic postgres instance pushed out.

I'm stuck on getting specific postgresql.conf variables set. For example I've tried

roles:
   - role::postgresql_puppetdb
      - wal_level: hot_standby

However that does get pushed to on subsequent agent run.

I'm hoping someone out there might have gone through trying to model PuppetDB configs in this manner and point out what I'm doing wrong.

share|improve this question
    
How exactly is your roles array being pulled in and used? Are you using hiera_include() at all or some kind of class declarations in site.pp based on what's in roles? –  Shane Madden Nov 19 '13 at 1:12

1 Answer 1

up vote 3 down vote accepted

For Puppet to lookup class parameters in Hiera (which it does by default since 3.0.0) these parameters need to be specified as simple key-value pairs, not complex datatypes.

This is how you would specify the datadir parameter of the class postgresql::server in the puppetlabs-postgresql module to point to an alternate data directory for Postgres:

# /etc/puppet/hieradata/foo.example.com.yaml
---
# Puppet automatically looks here for parameters when applying the class postgresql::server
postgresql::server::datadir: /srv/postgres/main

However, I don't think this is what you need in your case. You want to specify Postgres configuration parameters, for which you need to use the postgresql::server::config_entry defined type. There is currently no way to lookup type parameters in Hiera, that only works for class parameters.

So either you parameterize your role::postgresql_puppetdb class so you can pass class parameters to it, that in turn get fed into postgresql::server::config_entry declarations, or you use the create_resources() function together with hiera_array() or hiera_hash() to look up the Postgres configuration settings you want to apply.

An example for the first approach:

class role::postgresql_puppetdb (
  wal_level => 'minimal'
  ...
) {

  class { 'postgresql':
     ...
  }

  class { 'puppetdb':
     ...
  }

  postgresql::server::config_entry { 'wal_level':
    value => $role::postgresql_puppetdb::wal_level
  }
}

And then in Hiera.

# /etc/puppet/hieradata/foo.example.com.yaml
---
role::postgresql_puppetdb::wal_level: hot_standby

This is obviously a bit inflexible as you need to expose every tunable parameter and configuration setting the postgresql class provides through your role::postgresql_puppetdb class as well. Of course this might be enough for you if you know you only need to expose few tunables like this.

An example for the second approach:

class role::postgresql_puppetdb {

  class { 'postgresql':
     ...
  }

  class { 'puppetdb':
     ...
  }

  $postgres_config_entries = hiera_hash('postgres_configs', {})

  create_resources('postgresql::server::config_entry', $postgres_config_entries)

}

Then in Hiera:

# /etc/puppet/hieradata/foo.example.com.yaml
---
postgres_configs:
  wal_level:
    value: hot_standby
  authentication_timeout:
    value: 120s
  krb_server_keyfile:
    value: /var/lib/postgresql/postgresql.keytab

And so on. This is more flexible and allows you to set arbitrary Postgres parameters on every hierarchy level you want. In this case, of course, Hiera will only be consulted for these configuration settings when the role::postgresql_puppetdb class is included, but nothing keeps you from putting that hiera_hash-create_resources combo in other roles, possibly a role::postgresql.

I hope this was understandable and coherent enough to follow. The above is of course untested like posted, but we use this very strategy (create_resources, hiera_hash) to manage local and system accounts, repos, sudoers rules, Tomcat instances and others. Will revisit the question tomorrow when I am less tired.

But do have a look at this excellent question on Puppet-Ask: https://ask.puppetlabs.com/question/1655/an-end-to-end-roleprofile-example-using-hiera/

It walks through a similar setup based on HAproxy. Very useful to understand.

share|improve this answer
    
Thank you so much. I gave this a shot but I seem to be getting a "Error 400 on SERVER: can't convert Fixnum into Hash at " error during an agent run. It's pointing to a line number for the create_resources call –  atxdba Nov 19 '13 at 3:11
    
Nevermind, it was a problem with a typo in my yaml definition. –  atxdba Nov 19 '13 at 3:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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