Não foi possível encontrar a classe e, no entanto, ela está lá

Question

Ao fazer uma chamada puppet agent de uma nova imagem, recebo um erro err: Could not find class custommod . O próprio módulo está em /etc/puppet/modules/custommod igual a todos os outros módulos que estamos chamando, mas este é obstinante.

[site.pp]

node /clunod-wk\d+\.sub\.example\.local/ {
      include base
      include curl
      include custommod
      class{ "custommod::apps": frontend => "false}
      [...]
}

Quando o puppetmaster é executado com a saída de depuração, ele encontra claramente as informações para base e curl:

debug: importing '/etc/puppet/modules/base/manifests/init.pp' in environment production
debug: Automatically imported base from base into production
debug: importing '/etc/puppet/modules/curl/manifests/init.pp' in environment production
debug: Automatically imported curl from curl into production
err: Could not find class custommod for clunod-wk0130.sub.example.local at /etc/puppet/manifests/site.pp:84 on node clunod-wk0130.sub.example.local

A linha 84 é include custommod

Um diretório abreviado e estrutura de arquivos:

/etc/puppet
   |- manifests
   |     |- site.pp
   |
   |- modules
         |- base
         |    |- manifests
         |          |- init.pp
         |
         |- curl
         |    |- manifests
         |          |- init.pp
         |   
         |- custommod
              |- files 
              |     |- apps
              |         |- [...]
              |
              |- manifests
                    |- init.pp
                    |- apps.pp

Eu verifiquei a ortografia:}

O conteúdo de init.pp no diretório custommod é completamente normal:

class custommod {
}

A intenção é criar uma classe vazia para o arquivo apps.pp, que é onde está a carne.

class custommod::apps {

    [lots of stuff]
}

Apenas, nunca está chegando ao arquivo de aplicativos. Se eu comentar o include custommod , o erro acima será gerado na linha class{ "custommod::apps": frontend => "false} .

O que estou perdendo na minha busca para descobrir como esse erro está sendo gerado? Eu preciso observar que este repositório funciona bem se for executado localmente via puppet apply .

    

Answer 1

Então ... isso é um pouco embaraçoso, mas ...

Ambientes

Aí mesmo no meu arquivo /etc/puppet.conf está este:

[master]
  manifest=$confdir/manifests/site.pp
  modulepath=$confdir/environments/$environment/modules:$confdir/modules

Depois de jogar strace para descobrir onde estava procurando arquivos, notei algo. Ele estava procurando por custommod em /etc/puppet/environments/production/modules , e como havia um diretório lá (vazio), ele não executou a verificação /etc/puppet/modules . Aparentemente, ao importar um módulo, ele verifica a existência de diretório, em vez da presença de arquivo (init.pp).

Remover esse diretório vazio, as coisas começam a funcionar.

Execute o agente fantoche usando um ambiente diferente, as coisas começam a funcionar.

Moral da história:

Puppet Environment paths do not act like bash $PATH.

    

Answer 2

Eu encontrei esse mesmo problema, mas tive uma correção diferente

Se você gerar um módulo de fantoches da seguinte forma:

puppet module generate foo-example_module

Ele criará um módulo chamado example_module com o espaço de nome foo . Todos os manifestos estarão dentro de um diretório chamado foo-example_module

O nome da classe definida no init.pp precisa ser o mesmo que o nome da pasta.

Correção simples:

mv foo-example_module example_module

Se você usar o fantoche, ele avisará com a seguinte mensagem:

ERROR: example_module not in autoload module layout on line 42

Se você estiver usando um Puppetfile com r10k ou um bibliotecário-fantoche, você também pode precisar remover o espaço de nomes para que os arquivos sejam colocados sem o prefixo 'foo' no diretório de módulos.

antes:

mod 'foo-example_module',
    :git => [email protected]:foo/example_module'

depois:

mod 'example_module',
    :git => [email protected]:foo/example_module'

    

Answer 3

Outro problema que pode acontecer é quando o seu módulo tem um arquivo metadata.json inválido.

Verifique se o arquivo metadata.json tem todos os campos obrigatórios (consulte link )

    

Answer 4

Correu em um problema similar com o fantoche 3.7.1 para o Fedora: Não foi possível encontrar o fantoche de classe para my.server

Solução:

sudo ln -s /my/local/copy/puppet/modules /etc/puppet/

Então funciona.

    

Answer 5

Eu tive um problema semelhante. No meu caso, o nome da classe era "onehost :: change_IoT_password_reminder". Depois de usar strace, descobri que o fantoche estava procurando por um arquivo modules / onehost / manifests / change_iot_password_reminder.pp. Parece que usar letras maiúsculas nos nomes das classes não é uma boa ideia, mesmo que não seja a primeira letra da classe.