On Friday, October 26, 2012 7:33:00 AM UTC-5, Abhijeet Rastogi wrote:

On Fri 26 Oct 2012 04:42:56 PM IST, Calvin Walton wrote:
On Fri, 2012-10-26 at 13:16 +0530, Abhijeet R wrote:
------t1.erb -> I want to access value of $a and $b here. Using
mname::config::$a is not working. I am using <%=
scope.lookupvar("mname::config::$a" %> to get the value.
In templates, you don't use the $ character on variable names. If the
template is being used directly in the mname::config type, you can do
<%= @a %> (preferred)
<%= a %>
Sorry about using $a in templates. I actually wrote it by mistake and I
didn't use it in my actual templates. But, I have a requirement where
I've to use the values of $a, $b in other classes. Thing is like, some
resources that are defined in user-defined resource have to defined
only once and are common of two or more instances for defined resource.
So, I included that in a new class (Otherwise, multiple definition
errors come). Now, this class needs to use the values passed to defined
resource. (ie $a, $b). So, what should I do? This thing is works in 2.6
and 2.7.9 perfectly but it throws errors like

For classes -> warning: Dynamic lookup of $node_id at
/etc/puppet/modules/ucarp/manifests/up_down_scripts.pp:3 is deprecated.
Support will be removed in Puppet 2.8. Use a fully-qualified variable
name (e.g., $classname::variable) or parameterized classes.

That's a warning, not an error. Code that elicits such warnings works in
Puppet 2.7 the same way it worked in Puppet 2.6. Nevertheless, you should
fix the problem, and the message tells you how to do so.

For template -> warning: Dynamic lookup of $vip_addr_gw at
/etc/puppet/modules/ucarp/templates/vip-up.erb:6 is deprecated.
Support will be removed in Puppet 2.8. Use a fully-qualified variable
name (e.g., $classname::variable) or parameterized classes.

Again, that's a warning, not an error. If $vip_addr_gw is a local variable
in the context from which the template is evaluated, a parameter of the
class or definition that invokes template() or inline_template(), then it's
also bogus.

If I think of making a parametrised class instead of user-defined
resource, I'll be not be able to use that because I need to use that
class more than once for a node. (That is why I actually used
user-defined resource).

Class vs. defined type does not make a difference for issues of that kind.

TLDR - Few resources of a defined resource are to be defined only once
so are included in a class. How would that class be able to access the
parameters passed to the user-defined resource?

You can't, but you don't need to do it that way. At all.

1. Each class and definition should be in its own file
2. An object whose nature precludes being applied more than once should
be a class, not a definition
3. Any class's variables (except class parameters in some versions of
Puppet) can be accessed from anywhere in the manifest set by their
fully-qualified names (i.e. $module::class::variable)

That leaves you at least two options. If you convert the singleton
definitions to classes, then you can access their variables via their
fully-qualified names. If you want to leave them as definitions then you
can store the needed values as variables of some class (as I think you said
you did), and then read those class variables where you need them instead
of trying to access the parameter values of the defined-type instance.

Also, this defined
class is using templates to generate configuration files and needs to
access the parameters passed to defined resource. How should that be

It shouldn't. The big picture, in case it was not apparent in the
foregoing, is to pull the authoritative source of the needed values out of
the definition to some place accessible to everyone who wants it. Common
choices for such a place include variables of some class and external data
(perhaps accessed via hiera).


You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/J5PbZFhuVCsJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 6 | next ›
Discussion Overview
grouppuppet-users @
postedOct 26, '12 at 8:47a
activeOct 26, '12 at 7:29p



site design / logo © 2022 Grokbase