Ask Your Question

Automatic parameter lookup: best practice?

asked 2015-12-21 05:51:21 -0500

shulima gravatar image

When utilizing Puppet's automatic parameter lookup in Hiera, what is the better pattern: keep all parameters in init.pp and refer to them in subclasses (similarly to the old params.pp scheme), or skip the parameters in init.pp and use subclasses to set them?

Pattern 1: all parameters in init.pp, e.g.

class myapplication (
) {
  contain myapplication::ssh
  contain myapplication::ssl

class myapplication::ssl (
  $enable = $::myapplication::ssl_enable,
) { ... }

Pattern 2: parameters in subclasses, e.g.

class myapplication {
  contain myapplication::ssh
  contain myapplication::ssl

class myapplication::ssl (
) { ... }

With APL and Hiera, the latter seems cleaner and more sensible -- it's easier to figure out where to set the parameter, IMO -- but the obvious downside is that parameters aren't all in one place, so it's theoretically harder to find them. I haven't been able to find any opinions on the matter.

(I'm not using the params.pp model because the modules I'm making are for one OS only, and the only real application of params.pp that I can see, now that we have APL, is dealing with OS variants.)

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2015-12-21 22:57:06 -0500

I typically look at Puppet Labs supported modules in order to work out what is currently best practice. And from looking at a few here, pattern 2 seems to be mostly used.

Aside from that I feel fairly strongly that pattern 2 is a big improvement on pattern 1.

  1. I don't think finding the parameters is actually any harder; if you run grep -r ^myapplication hieradata/ you'll find all your parameters easily enough in either case.
  2. To understand myapplication::ssl in pattern 1, the developer needs two files open - ssl.pp and init.pp.
  3. Pattern 1 creates some action-at-a-distance which is always undesirable. Editing the class myapplication changes something in myapplication::ssl.

And I can't immediately think of any benefits in pattern 1. There may be edge cases where pattern 1 is required; so reserve it for these edge-cases I think, and possibly add comments to explain the reason you used it.

edit flag offensive delete link more


With pattern 2, if you need to use the same variable in multiple classes, do you just reference it in the scope of the other class? That would be the only primary upside to pattern 1 - variables used in multiple classes.

DarylW gravatar imageDarylW ( 2015-12-22 07:52:06 -0500 )edit

With pattern 2, the idea is that if you need a parameter in multiple subclasses, then it should be in init.pp (or perhaps params.pp). I feel that a subclass should have only its "own" parameters.

shulima gravatar imageshulima ( 2015-12-22 09:13:37 -0500 )edit

Alex: With PuppetLabs supported modules, it's usually all over the place due to design and API changes over the versions; with parameters in particular, since APL is fairly new. But I agree that pattern 2 feels better, I just don't necessarily have an explanation as to why. Yours works.

shulima gravatar imageshulima ( 2015-12-22 09:16:42 -0500 )edit

APL was new in Puppet 3 whereas we're up to Puppet 4 now. That's pretty old in Puppet years. :) I would expect that supported modules all have caught up by now, but to be sure, I haven't actually checked.

Alex Harvey gravatar imageAlex Harvey ( 2015-12-22 21:16:07 -0500 )edit

@dayrlw - the point is, looking up parameters in other classes is something I think should be avoided, unless you have a very good reason. I would use pattern 2 in day to day practice, and use pattern 1 only when you know that 2 isn't going to work for some reason.

Alex Harvey gravatar imageAlex Harvey ( 2015-12-22 21:18:12 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2015-12-21 05:51:21 -0500

Seen: 151 times

Last updated: Dec 21 '15