Class parameter flexibility with ENC, hiera or both

[Pablo Fernandez]

Dear puppetteers,

I am having a philosophical question about parametrized classes.
When building modules, one wants to be as flexible as possible, to try
to target as many puppet flavors as possible. This is our target:
- Foreman users, using foreman as an ENC with smart variables (or
potentially any other ENC, but I would say this is the most widespread one).
- Pure Puppet's site.pp users with Hiera as the only data binding.

But let's say that within mymodule there is a define mymodule::mydefine
that uses variable values from mymodule, let's say mymodule::parameter1.
I need to include mymodule to be able to use it, right? This is the example:

class mymodule (param1 = 'default_value') {
}

define mymodule::mydefine () {
include mymodule ## just to make sure it was parsed before
case (mymodule::param1) {blabla}
}

If you only use Hiera as a data backend, you're good: if you need to
override parameter1, you do it in the hierarchy, and the include does
not disturb you. But if you want to target also an ENC, you are screwed:

classes:
mymodule:
param1: 'value'

ENC's way to pass class parameters (if I am not mistaken) is the classic
"class {mymodule: param1 => 'value'}", and when the define does the
include without parameters, an error would come for mixing parametrized
and not parametrized inclusions.

The problem really comes because I need a variable from another class
(in the same module, though)... but:
- Is it possible to force the parsing order so that I don't need to use
the include inside the define?
- Or is it possible to have the ENC push parameters the "Hiera" way
instead of the "Classic" way, so that both includes are equivalent?


Thanks a lot,
Pablo Fernandez

[jcbollinger]

You have a serious misunderstanding there.  Mixing parameterized and unparameterized class declarations is not in itself erroneous.  The single constraint is that the (at most one) parameterized declaration of a given class must be evaluated before any declarations via the 'include', 'require', or new 'contain' functions.  I think that that may be automatically achieved when the class is declared via ENC, but if not then you may be able to achieve it by adjusting the order of classes in your ENC output.

Indeed, the issue you are driving at -- which is real -- is not much associated with use (or not) of an ENC.  I think you are more likely to encounter this problem in conjunction with parameterized-style class declarations appearing in manifests.
 

The problem really comes because I need a variable from another class
(in the same module, though)... but:
- Is it possible to force the parsing order so that I don't need to use
the include inside the define?

That's part of what the 'include' itself does.  I don't think there is any way to control the parse order from within your manifests that does not boil down to using 'include' or one of its brethren at some level.  But as I said, I don't think that's a problem in itself.

If your defined types are intended only for internal use within your module, however, then you could move the 'include' out of your definition by observing a requirement that such an 'include' be declared before any instance of your definition is declared.  I don't really think that's useful, but I mention it because it is responsive to your question.

 

- Or is it possible to have the ENC push parameters the "Hiera" way
instead of the "Classic" way, so that both includes are equivalent?

No such thing can be forced by a module; the behavior of an ENC is far outside modules' scope.  Nevertheless, an ENC could indeed be plugged in to the hiera infrastructure, either by writing a node-specific hiera data file before it returns its output, or by providing a custom hiera back-end that can be configured for the site.


John