*facepalm*  

For anyone else who encounters a problem like this and, like me, you are 
not a puppet administrator the first thing you should do is check the 
puppet master config (probably in /etc/puppet/puppet.conf) to see if it has 
reverted to a package supplied file rather than the customized file 
required to work with your ENC. Once you have determined this is the case, 
you should find where your administrator keeps the custom config file and 
replace it (tip: if it's stored as a template that will only be installed 
by running puppet to get a class list from the ENC this won't help and it 
needs to be done manually). Catalogs compile much happier when puppet 
actually uses the ENC.

Occam's razor in action, check the most likely cause of the problem first.

On Monday, December 23, 2013 3:50:23 PM UTC-5, Luke Alford wrote:
>
> I am having problems with our puppet/foreman infrastructure that seem to 
> coincide with an upgrade to 3.4.0-1, but that are persisting after a 
> downgrade back to 3.3.2-1. There are no obvious errors I can find and I 
> don't seem to be having any problems with puppet talking to foreman, so 
> overall things look completely normal other than I have puppet classes when 
> foreman responds with node information and an empty catalog after the 
> puppet master compiles. I am pretty stumped by this and would appreciate 
> any thoughts others may have on troubleshooting this problem.
>
> First, here's some more important information about our system. We had 
> been running puppet 3.3.2-1 and foreman 1.1-stable for quite some time 
> before things bumped up to 3.4.0 over the weekend.
> - centos 6.4 for puppet master and nodes
> - puppet and puppet-server 3.3.2-1 (I downgraded both puppet and 
> puppet-server back to this version since we'd been running successfully 
> with it for some time now)
> - puppetdb and puppetdb-terminus 1.5.0-1
> - foreman 1.1-stable (we've also been running this for some time, we don't 
> do any provisioning with it but we use it as an ENC for storing data and 
> classifying nodes into roles)
> - puppet and foreman running behind nginx/passenger
>
> If the upgrade to 3.4.0 was the sole source of my problem I would expect 
> things to have returned back to normal after the downgrade. Since the 
> catalog is still empty though, there's got to be something I'm missing. 
>
> Here are a few things I've tried while digging into this.
>
> 1) puppet master --compile <my node>
> The node is found, but there are no classes identified. Therein lies the 
> problem.
> ...
> "version": 1387830624,
>     "classes": [
>       "settings",
>       "default"
>     ],
>     "environment": "production"
> ...
>
> 2) Firing up irb, I manually checked what foreman returns for <my node>. I 
> won't post the whole output including parameters, but the important part is 
> that the keyset for the classes key in the yaml document matches what I 
> would expect for this particular monolithic test box.
> ...
> {"play"=>nil, "sudo"=>nil, "mongo"=>nil, "rsyslog"=>nil, 
> "mysql::server"=>nil, "jmx"=>nil, "nginx::loadbalancer"=>nil, "ssh"=>nil, 
> "play::install"=>nil, "mongo::seed"=>nil, "users"=>nil, 
> "mysql::server::master"=>nil, "logstash"=>nil, "common"=>nil, 
> "puppet"=>nil, "zabbix"=>nil, "motd"=>nil, "logrotate"=>nil, "java"=>nil, 
> "yum"=>nil, "ntp"=>nil}
>
> 3) I noticed that facter also updated to version 1.7.4 during this time, 
> but at least from what I've tried so far this doesn't seem to be a problem 
> of any kind.
>
> 4) Yes, I did try turning it off and on again. :)
>
> So it seems that somewhere between talking to the ENC and actually 
> compiling the catalog that my puppet classes disappear into the ether that 
> I have not yet identified. I would appreciate any suggestions people have 
> on further troubleshooting, or why the upgrade might have gotten things 
> into an odd state that rolling back the package somehow doesn't fix.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a4d7e044-2210-4d5f-8543-873331360f09%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to