0

I'm using the roles&profiles approach for my current puppet project.

The puppet best practices tell me:

  • Expose all necessary profile parameters in the main class parameter list.
  • Perform hiera lookups to fill in those parameters (having default values in module hiera)
  • Do not access variables in the scope of other modules/profiles
  • Be DRY (don't repeat yourself)

Now I'm facing the following problem (using puppet 5.5):

I have one basic profile that is included by all nodes (configuring apt, setting timezone, timeservers, etc...). Then I have several application-specific profiles (e.g. one for setting up IIS, one for settings up haproxy, etc...). Now I would like to add a log server to my application profiles. Of course I expect to specficy the log server only once in hiera (be DRY) but use it in all profiles.

My first approach is to add a log server parameter to the parameter list of my basic profile then access it from the application profiles using scoped variable access. But this contradicts the best practices because it adds a hidden interface/dependency between the modules.

Another approach I can come up with is to introduce a common hiera variable that I lookup with a explicit lookup. E.g.:

class profile::haproxy(
   Stdlib::Host $log_server = lookup('common::log_server'),
) {}

This also feels fishy to me.

So my question is: how would I share variables between modules/profile without violating the best practices?

C.Scharfenberg
  • 63
  • 7

1 Answers1

0

I'd use an interpolation function in the hiera itself:

common::log_server: foo
profile::haproxy::log_server: "%{lookup('common::log_server')}"
profile::iis::log_server: "%{lookup('common::log_server')}"

This keeps the profiles independent and maintains DRY.

Here is the puppet documentation for this technique.

Mark Wagner
  • 18,019
  • 2
  • 32
  • 47
  • Thanks Mark, I didn't know about this feature. I will try it out. – C.Scharfenberg Feb 07 '19 at 12:33
  • Just a minor style point, I usually keep any parameters not being passed directly into classes as single-namespace strings - for example `log_server` instead of `common::log_server`. The latter can very easily be mistaken for passing a value of `foo` to a parameter called `log_server` of a class called `common` - neither the class nor the parameter exist in this case. The lookup values would then be `lookup('log_server')`. – Craig Watson Feb 07 '19 at 15:23
  • This approach works nice for this case when I would like to access a simple value like a log server. But what if I need some post-processing on the pure hiera input? – C.Scharfenberg Feb 07 '19 at 16:13