In this particular scenario, I tend to lean toward having a 'content'
variable in my class or define.
class foo ( $content => template('foo/awesome.erb') ) { ... }
Someone wants to override that:
class { 'foo':
content => template('bar/my_awesome.erb')
}
I'm not sure if that covers 100% of the cases that you're concerned with,
but it tends to work well for me as a pattern.
Looking at many of the Forge modules, the main issue appears to me to be
that the authors are solving problem X and don't want to create a module
that handles X^Y configuration options due to time, cost, and manpower
issues (all of which are completely understandable). Also, the effort
required to understand and extend an elegant module may be more than people
are willing to put in to solve what is, otherwise, a 30 minute problem.
Finally, you run into the situation where someone did take the time to
create a completely awesome module but it's so granular that using quite a
few of them like that trends toward compiled graph bloat and code
complexity.
Hope this helps.
Trevor
On Fri, May 17, 2013 at 11:23 AM, Jeff Goldschrafe <[email protected]
> 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.frif
> 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.
>
>
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
[email protected]
-- This account not approved for unencrypted proprietary information --
--
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.
