Issue #19006 has been updated by John Moser.
File 792240_4697494708677_2092141553_o.jpg added
Doesn't look like it works that way. `$templatedir` is, for example,
`/etc/puppet/environments/$environment/templates`. You have a module `percona`
and you ask for `template(percona/loadbalance/haproxy/haproxy.cfg.erb`, it's
going to look in
`$moduledir/percona/templates/loadbalance/haproxy/haproxy.cfg.erb`.
I'm overloading templates here and supplying templates to modules. Consider an
`apache::vhost` that uses extremely customized settings that are
pattern-replicated. The defined type:
define apache::vhost(
$servername,
...
$template = 'apache/vhost.erb',
) {
...
}
makes a lot of sense.
Now, what you could do is just not do that, and then when somebody uses your
module they have to modify the code and the templates and supply their own
site-specific templates as part of the module. Then, they have to update to
the newer module, and do a git merge, and fix their changes into your changes...
There are clear cases where a node supplies a template to a class. It wasn't
even originally my idea; I forget who I stole it from. I refined it out though
and this is where it got me.
To be short, I disagree with the current conventions of [not] separating data
(templates) and code units (modules) in the same way the guy who wrote Heira
disagreed with the prior conventions of [not] separating data and code.
Templates are default data.
I can think of ways to specify this in the language (i.e. an explicit "overload
this template for this class/resource" that gets passed as a meta-parameter),
but that's worse: if the template overload isn't explicitly exposed, it's
internal ABI subject to change (they could rename the template file, and then
you're overloading a non-existent file). So the way Puppet does it now is
fine, and it's up to module developers to expose those kinds of knobs; but
Puppet carries a `$templatedir` variable that does nothing particularly useful
and is not exposed as a top level variable, yet is explicitly a per-environment
setting as if it's there for something.
The convention of rigid, inflexible, non-polymorphic code is dead. Locking
what are supposed to be extensible, reusable modules down to default data and
not allowing for customization without going in with a cutting torch and a
power drill is a poor way to go about things.
----------------------------------------
Bug #19006: per-environment templatedir doesn't actually work,
https://projects.puppetlabs.com/issues/19006#change-83235
Author: John Moser
Status: Needs More Information
Priority: Normal
Assignee: John Moser
Category: server
Target version: 3.x
Affected Puppet version: 3.0.2
Keywords:
Branch:
As per http://docs.puppetlabs.com/guides/environment.html
Puppet will only read the modulepath, manifest, manifestdir, and
templatedir settings from environment config blocks; other settings
in any of these blocks will be ignored in favor of settings in the
[master] or [main] blocks. (Issue 7497)
Issue #7497 covers the above.
What this issue covers is as such:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
No such file or directory - /percona/loadbalance/haproxy/haproxy.cfg.erb
With the node having (this is not best practice, but I'll find/write a module
later)
file { '/etc/haproxy/haproxy.cfg':
content =>
template("$templatedir/percona/loadbalance/haproxy/haproxy.cfg.erb"),
owner => 'root',
group => 'root',
mode => '0444',
notify => Service[ 'haproxy' ],
}
And /etc/puppet/puppet.conf on the Puppetmaster containing:
[dmz]
manifestdir = $confdir/environments/$environment/manifests
templatedir = $confdir/environments/$environment/templates
manifest = $confdir/environments/$environment/manifests/site.pp
The documentation indicates that this should work; however, it doesn't.
Using puppetmaster with Passenger here. Apache has been restarted since the
templatedir directive went into the config file.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" 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-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
