There are a few tickets floating around, like #7635, that deal with the
inability to specialize templates in standard Puppet. Among other things,
this is a limitation that makes it somewhat difficult for Forge module
authors to distribute truly reusable modules without providing a cadre of
non-interoperable custom functions to address this concern (see:
multi_source_template). These tickets propose very specific solutions in
terms of semantics. I'd like to open a broader feature discussion about how
templates can/should be specialized in Puppet manifests, if people think
they should be specialized at all. (I'm primarily concerned with templates,
but there's probably no reason this discussion couldn't also apply to
sourced files as well.)
I'm focused on the following three stories that I've seen come up on
lists/IRC from time to time:
- As a user, I want to provide different versions of a template
depending on some characteristic of the system so I don't need to encode
this differentiation logic into every manifest individually.
- As a module author, I want users to be able to specialize their own
templates without having to modify my module.
- As a Puppet administrator in an environment where templates/data are
change-controlled differently than manifest code, I want to provide users
the ability to produce new templates so they can make necessary changes
without altering any manifest logic.
--
As an example/starting point, here is a brief summary of my ideal
implementation of this in Puppet:
Most web servers provide a content-negotiation implementation where
different filenames are evaluated based on some characteristic of the
request/requestor. Typically, this is done using the Accept-Language
header, where the browser has specified that they would like a
representation of the content specific to their language, if that
representation is available. If the browser requests index.html and
specifies Accept-Language: fr, the web server can reply with index.html.fr
if that specific version is available, or index.html if it is not. Many
people are already using this model manually with file sources, providing
["puppet:///modules/mymodule/myfile.${osfamily}",
"puppet:///modules/mymodule/myfile"]. I'd love to see a less verbose
alternative that a) does this automatically based on configuration data
rather than code, and that b) works for templates.
At the same time, Puppet already provides hierarchical lookup features for
other forms of data via Hiera. Though Hiera can be used (somewhat
verbosely) for roughly this purpose, it seems natural to provide a similar
capability for template specialization as well.
Implementation discussions may tie into ARM-8 (Data in Modules) hierarchy
specification and the discussion on that ARM should be kept in mind.
Thoughts?
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" 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-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
