Puppet: definição condicional de tipos

Question

Não tenho a certeza de como formular estas questões, por isso sugiro uma edição se achar que é inadequado.

Estou tentando estender os módulos de fantoches existentes com o suporte de diferentes sistemas operacionais. Corri para um pequeno problema que não tenho certeza de como resolvê-lo de maneira elegante. No arquivo params.pp existe essa definição de pacotes específicos do SO para instalar:

case $::osfamily {
  'RedHat': {
    $package_server = 'mariadb-server'
    $package_client = 'mariadb'
    $php_package_name = 'php-mysql'
  }
...

O módulo é escrito de tal forma que toda a configuração depende de ter $php_package_name instalado. Eu quero exnted este módulo para o sistema operacional diferente, que não tem um pacote mysql separado para php, assim eu defino $php_package_name variable para undef . Isso traz um problema, esse fantoche tenta instalar o Package[undef] .

Qual seria uma boa maneira de evitar isso? Meus pensamentos até agora definem como false e têm toda a definição de $php_package_name fire somente if $php_package_name != false . Talvez exista uma maneira melhor?

    

Answer 1

Sim, isso parece uma abordagem razoável. Eu sugeriria uma ligeira variação, adicione um novo parâmetro que determine se o recurso package que usa $php_package_name deve ser aplicado:

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

Então, onde o recurso é:

if $thismodule::params::php_package_install {
  package { $thismodule::params::php_package_name:
    ensure => present,
    ...
  }
}

Tenha em mente que o método de fazer todo o material específico do sistema operacional em params.pp pode não acabar sendo mais limpo se os recursos necessários para a instalação no novo sistema operacional forem muito diferentes; Isso pode transformar seu arquivo de manifesto no ninho de condições e parâmetros de um ilegível rato. Nesse caso, não tenha medo de dividir o sistema operacional em uma classe separada (como install_el.pp para a família RedHat e install_otheros.pp para a nova família, com a correta sendo incluída de init.pp ou params.pp ).