Puppet users - Oct 2013 - Puppet components and configuration / Hiera patterns

We have embraced Hiera; we use the YAML configuration system currently and 
on the whole everyone finds it easy to use and intuitive.

However, as our manifests have grown more complex, we have a need to 
"compile" multiple narrowly-focused classes together into different
types
of high-level roles. For example, we might have a "webmail" class that
pulls together classes for configuring Apache, PHP, etc.  The low-level 
classes look to hiera for various configuration options -- e.g. Apache 
might look to Hiera for values on configuring server tokens or enabling the 
enhanced status or SSL information, PHP might want to check for 
security-related options configured, etc.

Ideally, we would like to expose simple values in the YAML file:

(e.g.)
---
webmail.use_https: true


Which gets translated into various "apache.*" configuration options. 
We
don''t want to make operators learn all the small levers that need to be
tweaked in the individual components in order to make the system function 
together.  

(I apologize if this particular example doesn''t make much real-world
sense;
this is somewhat contrived.)

I don''t think there''s a way to set Hiera options, right?  (I
haven''t seen
one; we''re on Puppet 2.7.x, so maybe newer Puppet does this
differently?)
 We could maybe use parameterized classes, but we are currently heavily 
reliant on the "singleton" guarantee with multiple includes.

Am curious how/whether others address this problem of abstracting 
configuration and using composition pattern to bring together small classes 
into sophisticated functionality?

Thanks in advance!

Hans

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On Thursday, October 24, 2013 10:21:39 AM UTC-5, Hans Lellelid
wrote:
>
> We have embraced Hiera; we use the YAML configuration system currently and 
> on the whole everyone finds it easy to use and intuitive.
>
> However, as our manifests have grown more complex, we have a need to 
> "compile" multiple narrowly-focused classes together into
different types
> of high-level roles. For example, we might have a "webmail" class
that
> pulls together classes for configuring Apache, PHP, etc.  The low-level 
> classes look to hiera for various configuration options -- e.g. Apache 
> might look to Hiera for values on configuring server tokens or enabling the
> enhanced status or SSL information, PHP might want to check for 
> security-related options configured, etc.
>
> Ideally, we would like to expose simple values in the YAML file:
>
> (e.g.)
> ---
> webmail.use_https: true
>
>
> Which gets translated into various "apache.*" configuration
options.  We
> don''t want to make operators learn all the small levers that need
to be
> tweaked in the individual components in order to make the system function 
> together.  
>
> (I apologize if this particular example doesn''t make much
real-world
> sense; this is somewhat contrived.)
>
> I don''t think there''s a way to set Hiera options, right? 
(I haven''t seen
> one; we''re on Puppet 2.7.x, so maybe newer Puppet does this
differently?)
>  We could maybe use parameterized classes, but we are currently heavily 
> reliant on the "singleton" guarantee with multiple includes.
>
>
You could indeed use parameterized classes, but I don''t recommend it, 
especially in Puppet 2.  In Puppet 3 I recommend them only in conjunction 
with automated data binding of all parameters.  That would be compatible 
with your existing code base, but it wouldn''t help you toward your
goal.

 
> Am curious how/whether others address this problem of abstracting 
> configuration and using composition pattern to bring together small classes
> into sophisticated functionality?
>
>
In Puppet, just like in other modular systems, composing modules into 
larger assemblies requires one or both of these things:

   - manipulating the exposed interfaces of the modules, or
   - creating some kind of glue code, wrapper, or adapter with which to 
   integrate modules into the assembly (which ultimately either depends on 
   access to module internals or breaks down to manipulating the exposed 
   interface)

Module interfaces consist of their classes intended for public use, the 
parameters of those classes (if any), the foreign variables they rely on, 
and the external data they consume.  If you don''t want users to have to
manipulate any of these directly, then you''ll need an indirection 
mechanism.  The most natural way to do this with Hiera would probably be 
through the data hierarchy, but that will break down quickly if there are 
more than a very small number of high-level parameters influencing the 
low-level module details.  That leaves writing indirection into your 
component modules'' DSL code.  One approach to that might look like
this:

class apache {
  $use_https_default = hiera(''apache::use_https'')
  $use_https = hiera(''webmail::use_https'', $use_https_default)
}

Yes, that would involve a lot of modifications to the component classes.

Alternatively, you could consider gluing things together via a custom Hiera 
back-end.  Such a back end would need to be very smart, or else would need 
to rely on some kind of pattern recognition to get its job done, but a 
custom back end would allow you to insert whatever logic you like into the 
data resolution chain.

Also, do not forget that Hiera supports array and hash values, which could 
provide an avenue to reducing the volume of code needed for indirection 
(perhaps a lot), depending on how you structure things.

I''m sorry if this is mostly high-level; I don''t really have
very much
concrete to work with here.


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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.