Vous pourriez ajouter Puppet à une tâche cron comme d'habitude (ce qui vous donne la possibilité de ne l'exécuter que pendant les heures de travail ou plus ou moins fréquemment que toutes les demi-heures) mais l'envelopper dans un court script qui vérifie si le numéro de révision de votre contrôle de source a été incrémenté. Si c'est le cas, il déclenche le client Puppet, sinon, il n'y a pas besoin de Puppet (et de tous les coûteux hachages de fichiers qu'il effectue).
Cela signifie toutefois que si vous modifiez un fichier sur un hôte, Puppet ne le modifiera pas. arrière jusqu'au prochain changement de configuration. Vous pourriez éviter ce problème en modifiant la logique du wrapper script pour exécuter également un client Puppet si plus de 24 heures se sont écoulées depuis la dernière exécution.
L'idée de Puppet "sans maître" (mentionnée par ewwhite) supprime le maître Puppet comme étant le goulot d'étranglement et le remplace par git comme étant le goulot d'étranglement, ce qui est largement préférable à mon avis. A moins que vous ne fassiez des changements dans git plus rapidement qu'il ne peut pousser ces changements vers tous les hôtes, ce goulot d'étranglement ne sera pas un problème. Vous pourriez arranger les "rayons" de manière arborescente si cela devenait un problème. Cela devrait permettre d'atteindre des dizaines de milliers d'hôtes.
