Sur un puppet master 6.X, je crée un nouvel environnement en reprenant la structure d'un environnement qui fonctionne sur un puppet master 5.X. Il fonctionne. Jusqu'à ce que j'essaye d'inclure un module depuis le manifest principal. L'agent puppet 5.5.X me retourne alors l'erreur suivante :
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Unacceptable location. The name '<NOM_MODULE>' is unacceptable
in file '/etc/puppetlabs/code/environments/<CENSURE>/site/modules/<NOM_MODULE>/manifests/init.pp' (file: /etc/puppetlabs/code/environments/<CENSURE>/site/modules/<NOM_MODULE>/manifests/init.pp, line: 3, column: 1) on node <CENSURE>
L'écrasante majorité des résultats d'une recherche web pointent sur un renforcement de la convention de nommage des fichiers et classes Puppet. La version 6.X ne laisse plus passer les écarts.
Je vérifie plusieurs fois : je respecte la convention de nommage imposée par Puppet.
En effet, voici mon arborescence :
/etc/puppetlabs/code/environments/envi
- modules
- manifests
- site.pp
- site
- modules
- modu
- manifests
- init.pp (qui contient la classe « modu »)
- profils
- manifests
- pro.pp (qui contient la classe « profils::pro »)
- roles
- manifests
- ro.pp (qui contient la classe « roles::ro »)
Et mon modulepath (dans environment.conf) : site:site/modules:modules
. Ce fichier est bien pris en compte comme nous le montre la commande suivante :
$ puppet config print modulepath --section server --environment envi
/etc/puppetlabs/code/environments/envi/site:/etc/puppetlabs/code/environments/envi/site/modules:/etc/puppetlabs/code/environments/envi/modules
Ainsi, un « include modu » depuis manifests/site.pp devrait fonctionner. Or, ça génère l'erreur mentionnée au début de ce shaarli.
En revanche, aucun problème avec un « include profils::pro » depuis manifests/site.pp.
Je te passe le debug : l'ordre dans le modulepath est important. Avec une valeur « site:site/modules:modules », Puppet cherche la classe d'abord dans le dossier site. « include profils::pro.pp » fonctionne puisque profils/manifests/pro.pp est bien dans le dossier site. En revanche, « include modu » ne fonctionne pas car, si site/modules/modu/manifests/init.pp existe, on ne peut pas l'inclure avec « include modu » sans outrepasser la convention de nommage. Il est d'autant plus difficile de parvenir à ce constat sur l''invalidité du modulepath puisque le message d'erreur de Puppet indique qu'il a trouvé le module (or, un path sert à trouver quelque chose…)
En changeant la valeur du modulepath pour site/modules:modules:site
, cela fonctionne, car le chemin « site/modules » est examiné d'abord et que site/modules/modu/manifests/init.pp existe et respecte la convention de nommage. Dans le cas de « include profils::pro.pp », rien est trouvé dans site/modules, ni dans modules/, donc la recherche se termine dans site/ et cela fonctionne car site/profils/manifests/pro.pp est trouvé.
Cela fonctionne aussi si le modulepath a pour valeur modules:site/modules:site
. Ce dernier est d'ailleurs le plus logique : on cherche d'abord dans les modules externes puis dans les modules maison, puis dans les profiles et les rôles maison.