Debugging a Node form site.pp?

[Joaquin Menchaca]

I was wondering is there is a way to see what puppet things a node resource is, such as classes it includes.  Somehow in our environment it is picking up a class that we did not specify. 

[jcbollinger]

On Tuesday, February 11, 2014 6:05:54 PM UTC-6, Joaquin Menchaca wrote:

I was wondering is there is a way to see what puppet things a node resource is, such as classes it includes.  Somehow in our environment it is picking up a class that we did not specify.

I could believe that you are getting a class that you did not realize you were declaring, or that you did not declare directly in manifest code written by you.  I could believe that the agent is applying a cached catalog that contains a class that once was declared for the target node, but no longer is.  I do not believe that the catalog compiler is randomly throwing in classes that were not in some way declared for the target node.

With that said, it's not altogether clear to me what you're actually asking.  I suspect that what you really want is to determine is where the unexpected class is declared, and for that purpose the 'grep' command is your friend.  Search for the class's unqualified, lowercase name in your manifests and hiera data.  If you use an ENC then you can run that manually and grep for the class name in its output.


John

[Joaquin Menchaca]

Is there a way to blow away the cache and refresh?  We don't use ENC in this environment, just a simple site.pp, which references nodes.pp. 

Segue, what I like about ENC is that you can call your homegrown script, get a yaml of params, classes for that node.  I wish I could get something similar with site.pp.  It would just be another level of debugging that could prove helpful.

This is what I have in a nutshell (simplified version):

nodes.pp
============
node /^stg-resque[0-9][0-9].mycompany.com$/ inherits base {
  $packages = [ 'ImageMagick', 'git', 'libxml2-devel', 'libxslt-devel', ... ]
  include network, nrpe, deployenv, deployenv::rvm, ...
}

The problem, is that there are deployenv, deployenv::passenger, and deployenv::rvm.  Somehow, deployenv::passenger is being picked up, even though it is not explicitly specified in the nodes.pp.

deployent/manifests/rvm.pp
================
class deployenv::rvm () {
  exec { gems: ... }
  exec { bundler: ... }
}

deployent/manifests/init.pp
================
class deployenv {
   group { deploy: ...}
   user { deploy: ...}
   file { .ssh: ...}
   file { deploy_dirs: ... }
}

deployent/manifests/passenger.pp
================
class deployenv::passenger () {
  file { nginx.conf: ... }
  exec { nginx_install: ...}

[Joaquin Menchaca]

Alright, I found the source of my problem, at least I think.  The puppetmaster includes path to modules based on an environment (staging, production, qa) and a global path shared by all environments.  The deployenv was in both locations, global and the environmental ones.  The module shared by everyone had "import passenger" in it. 

I still wish there was an easy way to generate a list from the site.pp manifests for debugging, similar to how an ENC can generate a YAML file of classes/params for the node.   What I did was go into /var/lib/puppet/client_data/catalog and looked at the json file to get some hints.

[jcbollinger]

On Wednesday, February 12, 2014 4:36:31 PM UTC-6, Joaquin Menchaca wrote:

Alright, I found the source of my problem, at least I think.  The puppetmaster includes path to modules based on an environment (staging, production, qa) and a global path shared by all environments.  The deployenv was in both locations, global and the environmental ones.  The module shared by everyone had "import passenger" in it. 

I still wish there was an easy way to generate a list from the site.pp manifests for debugging, similar to how an ENC can generate a YAML file of classes/params for the node.

You can't get a complete listing of all classes declared for a node with anything less than [the equivalent of] a complete catalog compilation.  And the catalog emitted by that process contains, in YAML form, details of all class and resource declarations pertinent to the node.

If you are using PuppetDB, then it caches the most recently-compiled catalog for each node.  You might therefore be able to query its "resources" terminus for the classes declared for your node, relying on the fact that Puppet tends to conflate classes and resources.

 

   What I did was go into /var/lib/puppet/client_data/catalog and looked at the json file to get some hints.

As I said, the catalog.


John