Home / server / Questions / 284259
Accepted
rvs
Asked: 2011-06-27 03:35:30 +0800 CST

Puppet: variable overriding best practices

  • 772

I'm wondering what are best practices for overriding variables in puppet. I'd like to have all my nodes (which located in different places, some of them are qa, some live) with same classes. Now I have something like this:

class base_linux {
   <...> # something which requires $env and $relayhost variables
}

class linux_live {
   $relayhost="1.1.1.1"
   $env = "prod"

   include base_linux
}

class linux_qa {
   $relayhost="2.2.2.2" # override relayhost

   include base_linux
}

class linux_trunk {
   $env = "trunk" # override env

   inlude linux_qa
}

node "trunk01" {
   include linux_trunk
   include <something else>
}
node "trunk02" {
   $relayhost = "3.3.3.3" # override relayhost
   include linux_trunk
   include <something else>
}

node "prod01" {
   include linux_prod
}

So, I'd like to have some defaults in base_linux, which can be overrided by linux_qa/linux_live, which can be overrided in higher level classes and node definition.

Of course, it does not work (and not expected to work). It does not work with class inheritance as well. Probably, I'll be able to archive using global scope variables, but it does not seems like a good idea to me.

What is the best way to solve this problem?

puppet

3 Answers

  1. 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")
    • 4
  2. Best Answer

    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
}
    • 2

  3. 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.

    • 1