puppetlabs-postgresql: como definir globais sem definições duplicadas

Question

A documentação do puppetlabs-postgresql recomenda a definição de valores em postgresql :: globals da seguinte forma:

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

No entanto, isso não funciona:

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

Porque postgresql :: client herda de postgresql :: parameters, que herda de postgresql :: globals. Então, quando chega à instanciação explícita da classe postgresql :: globals, ele reclama de uma definição duplicada.

alterando a ordem, funciona:

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

No entanto, em uso real, minha instanciação de postgresql :: client e postgresql :: server estão em classes diferentes associadas a classes de servidor que eu uso, e eu realmente não quero estar criando uma ordenação requerida para essas classes. Além disso, quero que as definições globais se apliquem ao postgresql :: client, mesmo em servidores que não executam postgresql :: server.

Se estivéssemos usando puppet 3.x, eu definiria os valores globais necessários em hiera, mas ainda estamos no fantoche 2.7.

Existe uma maneira de corrigir isso sem modificar a distribuição dos puppetlabs? Atualmente, estou pensando que isso pode justificar um relatório de bug para puppetlabs, mas ainda me pergunto se estou perdendo uma solução simples.

EDIT: depois de ler a entrada de @ FelixFrank, criei um relatório de erros no link .

    

Answer 1

Sim, Hiera seria a melhor solução. Note que você pode (e deve) adicionar Hiera ao Pupet 2.7.x no formulário do plugin.

Salvo isso, suas opções são limitadas. A relação require entre duas classes não terá efeito. Pelo contrário, observe que a seguinte refatoração do seu manifesto de trabalho também gera o seu erro:

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

O motivo é que o problema é baseado em ordem de análise ou ordem de avaliação - a ordem em que o compilador de manifesto encontra as declarações de classe. Os parâmetros require/before (e as setas de encadeamento) apenas adicionam relacionamentos ao catálogo que está sendo construído, para consumo pelo puppet agent .

Basicamente, você deve garantir que sua própria classe de servidor PostgreSQL seja sempre avaliada antes da classe do cliente, por exemplo

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

Tal ordenação nem sempre pode ser garantida em manifestos complexos (que podem include especialmente a funcionalidade do cliente de numerosos contextos). Como tal, acho que há um strong argumento para declarar isso como um bug no módulo. Uma vez que os padrões que levam ao problema são bastante difusos (acho), pode haver motivos para questionar a prática atual de design de módulo em geral.

Vou ver mais algumas opiniões da comunidade sobre isso.