puppet 3 + hiera + "cross modules references"

[Jean Baptiste Favre]

Hello,
I'm trying to figure out how I can use puppet 3 & hiera in an efficient way.

Let's say that I've two classes:
class foo ( $param ) {
notify {"foo": message => "value is ${foo::param}"}
}
class bar ( $param ) {
notify {"bar": message => "value is ${bar::param}"}
}

My hiera file looks like:
---
foo::param: value
bar::param: value

Everything works fine with node:
node mynode {
include foo
include bar
}

Now, let's imagine that I need bar::param to have same value than
foo::param. One way could be to update both of them. But then I need to
make sure that they're always synced. Not so good.

The other way should be to put foo::param as bar::param value, like:
---
foo::param: value
bar::param: %{foo::param}

This works, if and only if I include class foo in my node recipe.
Of course I still could set bar class as follow:
class bar ($param = hiera('foo::param')) { ... }

But, in that case, it introduced a dependency between both classes.
And when classes comes from different modules, this is not always the
desired behavior.

What I would like to do is making hiera resolves "reference" and
automatically retrieve foo::param value, even if foo class is not included.
Use case could be to define some global value like web application
parameters like hostname which should be defined globally and used when
needed.

Any comment welcomed.
Regards,
Jean Baptiste

[jcbollinger]

There are some important question to answer here to determine the best course of action:

1. why are the values for foo::param and bar::param the same?  If it is circumstantial or coincidental, then squeezing out the duplication is probably harmful rather than helpful.  In that case I would recommend just having duplicate data
2. Supposing that there is a functional reason why the two parameters are the same, the next question is who owns the data?  If one of the classes is the logical owner, then it is right for the other to depend on it.

If the data are fundamentally the same, but neither class can reasonably be construed as its owner, then it ought to be given to some third entity on which both the others can rely.  That "entity" might be an actual class, or it might just be a separate logical namespace for the Hiera key.
 

What I would like to do is making hiera resolves "reference" and
automatically retrieve foo::param value, even if foo class is not included.

I think that's a bad idea because it hides the logical relationship among your classes in your data instead of making it evident in your classes.

If you insist on pursuing such a course, however, then you should investigate whether the underlying YAML parser supports YAML 1.2.  That version of YAML has a built-in mechanism for aliasing data elsewhere in a document, which should accomplish what you seek.  Think again, though.

 

Use case could be to define some global value like web application
parameters like hostname which should be defined globally and used when
needed.

That sort of thing really ought to be pulled out to its own class.  Example:

class webapp::server {
  # Note: hides the $::hostname fact
  $hostname = hiera('webapp::server::hostname')
}

class webapp::app1 {
  include 'webapp::server'
  # use $webapp::server::hostname ...
}

class webapp::app2 {
  include 'webapp::server'
  # use $webapp::server::hostname ...
}



John