Comment examiner la sortie de Jinja dans Saltstack?

J'ai un modèle SLSdans Salt que j'essaie de construire, mais il émet une syntaxe non valide, ce qui entraîne des erreurs telles que:

my-minion-id:
    - State 'system' in SLS 'network' is not formed as a list

En principe, il devrait être possible, d'une manière ou d'une autre, d' examiner la sortie du modèle Jinja avant de tenter d'analyser la sortie en tant que SLSfichier. Il existe un module Python pour le rendu Jinja salt.renderers.jinja, mais si j'essaie de l'exécuter sur la CLI, j'obtiens une erreur:

# salt my-minion-id salt.renderers.jinja.render /srv/salt/network/init.sls
my-minion-id:
    'salt.renderers.jinja.render' is not available.
ERROR: Minions returned with non-zero exit code
# salt my-minion-id renderers.jinja.render /srv/salt/network/init.sls
my-minion-id:
    'renderers.jinja.render' is not available.
ERROR: Minions returned with non-zero exit code

Comment puis-je voir la sortie de mon modèle? Il semble absurde que cela devrait être difficile à déboguer.

Découvrez le module slsutil.renderer .

Cela devrait faire ce que vous voulez

salt my-minion-id slsutil.renderer /srv/salt/network/init.sls 'jinja'

Ce module appelle simplement la fonction compile_template directement pour vous.

Edit: /srv/salt/network/init.sls est le chemin sur le serviteur, si vous ne ciblez pas le maître comme votre serviteur, vous devrez probablement faire ce qui suit.

salt minion-id cp.cache_file salt://network/init.sls
salt minion-id slsutil.renderer /var/cache/salt/minion/files/base/network/init.sls

ou pointez sur le fichier que cache_file crache.

Si vous êtes sur 2018.3 ou plus récent, vous pouvez simplement spécifier salt://network/init.sls

Étant donné le temps que j'ai passé il y a des semaines à lutter contre un problème étroitement lié, j'aurais aimé comprendre cela plus tôt.

La solution semble être d'utiliser salt.modules.cp.get_templatepour que le séide récupère le fichier, le rende via le moteur de modèle et le place dans un endroit lisible:

# salt my-minion-id cp.get_template salt://network/init.sls /root/network.sls template=jinja
my-minion-id:
    /root/network.sls

De là, vous vous connectez à l' my-minion-idhôte et examinez le fichier dans lequel vous l'avez placé /root/network.sls.

C'est logique; salt.renderers.jinjase trouve dans l' salt.renderersespace de noms, tandis que les modules auxquels vous avez accès depuis la CLI se trouvent dans l' salt.modulesespace de noms.

Il est également logique du point de vue de la visibilité des données; le rendu de modèle se produit sur le serviteur , où les grains et autres sont disponibles, et je n'ai pas encore vu un module qui exécute le code du serviteur renvoyer une sortie arbitraire au maître (pour une vue sur la CLI, par exemple); les données renvoyées sont invariablement bien structurées et concises. (Il peut y avoir un tel module, mais je ne sais pas de quoi il s'agit. Ce serait une solution préférable à la suppression de fichiers de test sur un serviteur.)

edit: la réponse de @ gtmanfred est bien meilleure et plus directe, et je l'ai acceptée. Je laisse celui-ci ici à des fins informatives. Ce n'est pas la meilleure solution, mais cela fonctionne toujours.