Eu tenho alguns casos de uso em que quero definir vários recursos semelhantes que devem terminar em um único arquivo (por meio de um modelo).
Como exemplo, estou tentando escrever um módulo de fantoches que me permitirá gerenciar o mapeamento entre endereços MAC e nomes de interfaces de rede (escrevendo o arquivo persistent-net-rules do udev a partir do fantoche), mas também há muitos outros usos semelhantes casos.
Pesquisei e descobri que isso poderia ser feito com a nova sintaxe classes com parâmetros : se implementado dessa forma, deve acabar sendo usado assim:
node { "myserver.example.com":
class { "network::iftab":
interfaces => {
"eth0" => { "mac" => "ab:cd:ef:98:76:54" }
"eth1" => { "mac" => "98:76:de:ad:be:ef" }
}
}
}
Nada mal, concordo, mas explodiria rapidamente quando você gerencia coisas mais complexas (pense em configurações de rede como neste módulo ou qualquer outro material recursos com vários recursos complexos em um único arquivo de configuração ).
Em uma pergunta semelhante sobre SF alguém sugeriu usar módulo puppet-concat do Petenaar mas duvido que possa ser melhor do que as classes parametrizadas.
O que seria muito legal e limpo na definição de configuração seria algo como o tipo de host incluído , seu uso é simples, bonito e limpo e, naturalmente, é mapeado para vários recursos que acabarão sendo configurados em um único local. Transposto para o meu exemplo, seria como:
node { "myserver.example.com":
interface {
"eth0":
"mac" => "ab:cd:ef:98:76:54",
"foo" => "bar",
"asd" => "lol",
"eth1":
"mac" => "98:76:de:ad:be:ef",
"foo" => "rab",
"asd" => "olo",
}
}
... parece muito melhor aos meus olhos, mesmo com opções de 3x para cada recurso.
Devo realmente passar matrizes para classes parametrizadas ou existe uma maneira melhor de fazer esse tipo de coisa? Existe algum consenso aceito na comunidade de bonecos [usuários | desenvolvedores]?
A propósito, estou me referindo à versão estável mais recente da ramificação 2.7 e não estou interessado em compatibilidade com versões mais antigas.