On Nov 16, 9:16 am, Theo Cabrerizo Diem <d...@carpediem.sh> wrote:
> Hi All,
>
> I have a define-type resource, which gets called from multiple classes, on
> which I would like to read its parameters from a template. This works for
> parameters added to the call of the resource but not for those which have a
> "default" value on its definition.
>
> On the example below, I can read the parameter from Webdir[c] but not from
> a and b.
> If webdir would be a class type instead (and with the restriction of being
> able to call it only once) it would work, since
> resource("Webdir[a]").parameters includes the ones set by default on the
> class definition.
>
> Is this intended or a bug ?
I don't know, but parameterized classes do not serve as a reasonable
reference for how defined type instances should behave. I do suspect,
however, that the behavior you observe is not only intended, but also
consistent with the behavior of native resource instances (see below).
> I know that using a native define-type (those written in ruby) I can access
> the parameters as intended
Really? I'm not a big templating guy, but if you declare, say
service { 'frob': enable => true }
then what does the following template output?
"<%= scope.findresource("Service[frob]")['hasstatus'] -%>"
The built-in Service type defines a default value for its hasstatus
property, but I predict (instead of testing ... dangerous :-) ) that
the template will evaluate to a blank / empty string. That would be
exactly analogous to your case.
> but, like the example below, it is nice to have
> the simplicity for doing the same on define-type resources when they
> contain other resources such as file, services, vcsrepo, etc.
I understand, but really you ought to go at it a different way. A lot
of people seem inclined to want in one part of their manifests to
interrogate Puppet about what they themselves declared in a different
part of their manifests. With some notable exceptions, that is a
Puppet anti-pattern.
For the case at hand, I would recommed using the Concat module to
build your httpd configuration from pieces. Each webdir instance
would declare an appropriate fragment, using the knowledge it already
has about its own parameter values. Alternatively, you could let each
webdir manage its piece of the configuration as a separate file, and
make httpd.conf (or whatever) interpolate them all.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
