Puppet users - Dec 2013 - Class parameter flexibility with ENC, hiera or both

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


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/529CC5E7.8010800%40cscs.ch.
For more options, visit https://groups.google.com/groups/opt_out.

On Monday, December 2, 2013 11:39:51 AM UTC-6, pablo.f...@cscs.ch
wrote:
>
> 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. 
>

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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/d03161d1-5e8e-49f6-8625-3fbd777c28ff%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.