On 2013-17-05 8:23, Jeff Goldschrafe wrote:
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?
There are features in ARM-3 (Puppet Templates) that will help with
several of the issues. One such feature is the ability to pass
parameters to the template, and that a template can nest other templates.
https://github.com/puppetlabs/armatures/blob/master/arm-3.puppet_templates/puppet_templates.md#passing-arguments-to-the-template
The ARM-8 (Data in Modules) is also important and work is underway to
define a successor to Hiera ("Hiera 2") with a more general binding scheme.
Puppet Templates is implemented and can be tried out (information in the
ARM).
regards
- henrik
--
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 puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
