Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am working on a refactoring project for a large repository of custom puppet modules. This includes an upgrade from puppet 2.x to 3.2.4. When I finally hit critical mass and started testing some of the changes, I quickly ran into the following error:

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

After looking through various puppet bug reports, I decided to try simplifying the problem. I narrowed the issue down to two classes, defined as such:

class base::includes { }

and

class prod_secure::base::includes inherits base::includes { }

A node that includes nothing but prod_secure::base::includes produces the error output listed above. The only possibly related warning that I see in puppet-lint is:

WARNING: class inherits across module namespaces on line 1

...but that's just a warning, and shouldn't crash puppet on an agent run, I wouldn't think. Any ideas? Is it possible that the namespacing scheme that I have set up unsupported by puppet?

UPDATE

I decided to take the testing a step further, and change the name of the inheriting class. The new definition is:

class prod_secure::base2::includes2 inherits base::includes { }

The result is the same... stack level too deep. It looks to me like this issue has nothing to do with namespacing.

UPDATE 2

During the previous round of debugging I missed one salient detail:

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

I can't say I'm sure why, but it was still trying to load prod_secure::base::includes, and that was the offending entry. After removing that file entirely, the test passed. I'm back to the namespacing theory...

share|improve this question
    
Do you have a module that tries to load 'modulename/*.pp' manually, as a work for some autoloader problems way back in Puppet 0.25.x? I've seen this cause problems with modern versions of Puppet. –  jgoldschrafe Sep 9 '13 at 12:30
    
Just checked and...no. –  ajk8 Sep 9 '13 at 15:15

1 Answer 1

You might want to try puppet 3.2.3.

3.2.2 had #21376 similiar problem, but it was fixed in 3.2.3, it might be regression

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.