Para que o Puppet pesquise parâmetros de classe no Hiera (o que ele faz por padrão desde a 3.0.0), esses parâmetros precisam ser especificados como pares de valor-chave simples, não tipos de dados complexos.
É assim que você especificaria o parâmetro datadir da classe postgresql::server no módulo puppetlabs-postgresql para apontar para um diretório de dados alternativo para o 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
No entanto, acho que não é isso que você precisa no seu caso. Você deseja especificar os parâmetros de configuração do Postgres, para os quais você precisa usar o tipo postgresql::server::config_entry defined. Não há atualmente nenhuma maneira de procurar parâmetros de tipo no Hiera, que só funciona para parâmetros de classe.
Portanto, você parametriza sua classe role::postgresql_puppetdb para poder passar parâmetros de classe a ela, que por sua vez são alimentados em declarações postgresql::server::config_entry , ou use a função create_resources() junto com hiera_array() ou hiera_hash() para procure as configurações do Postgres que você deseja aplicar.
Um exemplo para a primeira abordagem:
class role::postgresql_puppetdb (
wal_level => 'minimal'
...
) {
class { 'postgresql':
...
}
class { 'puppetdb':
...
}
postgresql::server::config_entry { 'wal_level':
value => $role::postgresql_puppetdb::wal_level
}
}
E depois em Hiera.
# /etc/puppet/hieradata/foo.example.com.yaml --- role::postgresql_puppetdb::wal_level: hot_standby
Isso é obviamente um pouco inflexível, já que você precisa expor todos os parâmetros ajustáveis e configurações que a classe postgresql fornece através da sua classe role::postgresql_puppetdb também. É claro que isso pode ser suficiente para você, se você sabe que precisa expor apenas alguns ajustes como este.
Um exemplo para a segunda abordagem:
class role::postgresql_puppetdb {
class { 'postgresql':
...
}
class { 'puppetdb':
...
}
$postgres_config_entries = hiera_hash('postgres_configs', {})
create_resources('postgresql::server::config_entry', $postgres_config_entries)
}
Então em 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
E assim por diante. Isso é mais flexível e permite que você defina parâmetros arbitrários do Postgres em cada nível de hierarquia desejado. Nesse caso, é claro, o Hiera só será consultado para essas configurações quando a classe role::postgresql_puppetdb estiver incluída, mas nada impede que você coloque o combo hiera_hash-create_resources em outras funções, possivelmente role::postgresql .
Espero que isso tenha sido compreensível e coerente o suficiente para seguir. O acima, claro, não foi testado como publicado, mas usamos essa mesma estratégia (create_resources, hiera_hash) para gerenciar contas locais e do sistema, repos, sudoers, instâncias do Tomcat e outras. Vou revisitar a questão amanhã quando estiver menos cansado.
Mas dê uma olhada nessa excelente pergunta sobre Puppet-Ask: link
Ele percorre uma configuração semelhante com base no HAproxy. Muito útil para entender.