Ich arbeite an einem Refactoring-Projekt für ein großes Repository mit benutzerdefinierten Puppet-Modulen. Dazu gehört ein Upgrade von Puppet 2.x auf 3.2.4. Als ich endlich die kritische Masse erreicht hatte und mit dem Testen einiger Änderungen begann, stieß ich schnell auf den folgenden Fehler:
Info: Retrieving plugin
Info: Loading facts in /etc/puppet/modules/base/lib/facter/elversion.rb
Info: Loading facts in /etc/puppet/modules/base/lib/facter/site.rb
Info: Loading facts in /var/lib/puppet/lib/facter/elversion.rb
Info: Loading facts in /var/lib/puppet/lib/facter/site.rb
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: stack level too deep at /etc/puppet/manifests/nodes.pp:9 on node puppet
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
Nachdem ich mir verschiedene Puppet-Fehlerberichte angesehen hatte, beschloss ich, das Problem zu vereinfachen. Ich grenzte das Problem auf zwei Klassen ein, die wie folgt definiert waren:
class base::includes { }
Und
class prod_secure::base::includes inherits base::includes { }
Ein Knoten, der nichts anderes als prod_secure::base::includes enthält, erzeugt die oben aufgeführte Fehlerausgabe. Die einzige möglicherweise damit zusammenhängende Warnung, die ich sehe, puppet-lintist:
WARNING: class inherits across module namespaces on line 1
...aber das ist nur eine Warnung und sollte Puppet bei einem Agent-Lauf nicht zum Absturz bringen, denke ich. Irgendwelche Ideen? Ist es möglich, dass das von mir eingerichtete Namensraumschema von Puppet nicht unterstützt wird?
AKTUALISIEREN
Ich habe beschlossen, beim Testen noch einen Schritt weiterzugehen und den Namen der erbenden Klasse zu ändern. Die neue Definition lautet:
class prod_secure::base2::includes2 inherits base::includes { }
Das Ergebnis ist das gleiche.... stack level too deepFür mich sieht es so aus, als hätte dieses Problem nichts mit dem Namespace zu tun.
AKTUALISIERUNG 2
Während der letzten Debugging-Runde habe ich ein wichtiges Detail übersehen:
Wed Sep 11 11:25:09 -0400 2013 Puppet (info): Caching node for puppet
Wed Sep 11 11:25:09 -0400 2013 Puppet (debug): importing '/etc/puppet/manifests/nodes.pp' in environment production
Wed Sep 11 11:25:09 -0400 2013 Puppet (debug): importing '/etc/puppet/manifests/config_file.pp' in environment production
Wed Sep 11 11:25:10 -0400 2013 Puppet (debug): importing '/etc/puppet/modules/prod_secure/manifests/base2/includes2.pp' in environment production
Wed Sep 11 11:25:10 -0400 2013 Puppet (debug): Automatically imported prod_secure::base2::includes2 from prod_secure/base2/includes2 into production
Wed Sep 11 11:25:10 -0400 2013 Puppet (debug): importing '/etc/puppet/modules/prod_secure/manifests/base/includes.pp' in environment production
Wed Sep 11 11:25:10 -0400 2013 Puppet (debug): Automatically imported prod_secure::base::includes from prod_secure/base/includes into production
Wed Sep 11 11:25:10 -0400 2013 Puppet (err): stack level too deep at /etc/puppet/manifests/nodes.pp:9 on node puppet
Wrapped exception:
stack level too deep
Ich kann nicht sagen, warum, aber es versuchte immer noch, prod_secure::base::includes zu laden, und das war der fehlerhafte Eintrag. Nachdem diese Datei vollständig entfernt wurde, war der Test erfolgreich. Ich bin wieder bei der Namensraumtheorie …
Antwort1
Vielleicht möchten Sie Puppet 3.2.3 ausprobieren.
3.2.2 hatte#21376ähnliches Problem, aber es wurde in 3.2.3 behoben, es könnte eine Regression sein