Puppet: variable overriding best practices

The best practice depends on the number of nodes/systems you manage. Modeling data in puppet manifests is sufficient if you can keep track of the data (I've seen it done with thousands of systems, however it gets challenging if you have a large number of variables and deep inheritance especially if you start referencing by scope such as $value = $some_class::some_var). If you have a complex infrastructure it makes sense to look at separating the data from puppet manifests using extlookup, heira, or an external node classifier (ENC).

The way you have done it in the puppet manifests is using dynamic scoping and node inheritance, and dynamic scoping is being deprecated in Puppet 2.7. If this is rewritten in extlookup, it would simply be:

# configured globally
# linux_qa is more likely linux_%{env}
$extlookup_precedence = ["%{fqdn}", "linux_trunk", "linux_qa", "common"]

# in the appropriate class
$relayhost = extlookup("relayhost")

It seems I've found nice way to do this: instead of defining variables in classes, it's better to make variable-only node templates. So, I've end up with something like following:

node basenode {
}

node linux_prod inherits basenode {
  $relayhost="1.1.1.1"
  $env = "prod"
}

node linux_qa inherits basenode {
  $relayhost="2.2.2.2"
}

node linux_trunk inherits linux_qa {
  $env = "trunk"
}

class base_linux {
  # no valuables defined here
  <...>
}

node trunk01 inherits linux_trunk {
   $relayhost = "3.3.3.3" # I can override here for single node
   include base_linux
}

My own suggestion is not to put the variables on classes -- only if that class needs to override something.

Put your variables inside site.pp (or some imported file -- I name mine globals.pp), put the rules to discern what the values they should have there -- choose instead of override. Then you can do individual overrides on nodes or classes as you wish.