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