2

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?

4 Answers 4

1

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.

1
  • 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. Mar 16, 2011 at 15:51
2

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:

[master]
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.

1

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.

1
  • Extlookup is a new one on me, but looks like a fantastic approach to this issue; many thanks for the pointer! Mar 16, 2011 at 15:50
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .