Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a puppet module to setup several Gigaspaces PU's. Each of these have quite a few variables to be placed within the configuration file templates. We're also using several different environments so these variables are repeated several times to contain the values for each environment.

My question is where the best place to store these variables would be? A class of their own, an external .pp I import, or something other?

share|improve this question
up vote 1 down vote accepted

A lot of what you're asking comes down to convention more than strict language requirements... The language is flexible enough to do things a number of different ways.

If all the servers are being configured the same, it should work fine to have a single "gigaspace" class with the variables set at the top.

If your needs are more complicated than a single class of server, what I would do is create a "gigaspace" module with a common class holding variables inherited by classes needing the variables. In gigaspace/manifests there'd be an "init.pp" containing "class gigaspace {...}", and then a "common.pp" containing "class gigaspace::common {...}". Then in any class that I needed access to those variables, I would inherit from the common class, like "class gigaspace::master inherits gigaspace::common { ... }".

If you don't inherit from the other class, it's a pain to get at variables in another class, especially from within a template. With a straight include you can get read-only access via specifying the whole name, however.

share|improve this answer
This sounds like the approach we'll have to use for the moment and is a logical step from the current pattern of simply including a file with the values in it; many thanks for the answer. – Michael Duffy Mar 16 '11 at 15:51

I'm a big fan of using an external node classifier for setting variable=value at top scope. That way you can use a real datastore and programming logic to determine what the values ought to be for a given node, rather than pile a bunch of puppet-language conditionals into a messy variables.pp type of file. Inheritance and scoping are two big areas in Puppet that don't work as many folks expect, and indeed have their own caveats and issues even if you know what to expect; without external nodes you're going to need one or both of them.

The way an external node classifier works is that you configure your puppetmaster's puppet.conf to run it:

node_terminus = exec
external_nodes = /path/to/my/classifier.rb

The master executes it every time a client connects with a command-line argument of the connecting client's certificate name. Your code does whatever you need and returns YAML with a list of classes: which ought to be included for the node and a list of parameters: which are set as top-scope variables for use in manifests and templates.

There are a couple of sample classifiers in the ext/ directory of the source distribution. It's a super way to solve the "Reasonable Defaults, Plus Overrides Where I Need Them" problem.

share|improve this answer

There are two recommendations I commonly see for this. One is to use an external node classifier, like eric sorenson suggested. Another is to use extlookup. Extlookup is easy to use and is included with puppet as of version 2.6.1. I've been happy with it.

share|improve this answer
Extlookup is a new one on me, but looks like a fantastic approach to this issue; many thanks for the pointer! – Michael Duffy Mar 16 '11 at 15:50

You can have a variables.pp manifest inside your module that is called by your other modules. This is the most common thing I have seen. For the environment variables I would take a look at some of the facter facts and see if you can use those. If you can post an example of your module I might be able to give more detail.

share|improve this answer

Your Answer


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.