Issue #14985 has been updated by Steven Roberts.
I applied the changes from pull/1214. Works fairly well. calling_module is
working as expected.
For calling_class though, the behavior was not as I originally thought, but
thinking about it understandable.
if I have:
class baz::foo ($bar => undef)
and in nodes.pp:
node mynode {
class {'baz::foo': }
}
# so hiera will auto-bind the param
I get calling_class looks to be undefined, and calling_module is 'baz'
but if I run hiera(baz::foo::bar) from inside of baz::foo, calling_class is
'baz::foo' and calling_module is 'baz'
I am guessing that is because the auto-bind hiera param behavior is doing it
from the scope of the node and not the class.
----------------------------------------
Bug #14985: calling_module and calling_class don't always return the calling
module/class
https://projects.puppetlabs.com/issues/14985#change-83371
Author: Patrick Ramsey
Status: In Topic Branch Pending Review
Priority: Normal
Assignee:
Category:
Target version: 3.x
Affected Puppet version: 3.0.0
Keywords: hiera calling_class calling_module defined_type
Branch: https://github.com/puppetlabs/puppet/pull/1214
These two special hiera scope values are looked up by doing ".resource.name" on
the Puppet::Parser::Scope from which hiera() was called, with the assumption
that this will always return the class name. However, if hiera() is called
from within a define, then @real.resource will be an instance of that define,
rather than of the class, and the value returned will be the name of that
resource rather than of the class.
This is unintuitive (as it means calling_module/calling_class aren't set to a
module or classname), and it breaks the ability to namespace against
calling_class and title (to give specific resources their own configuration) a
la
:hierarchy: - %{calling_class}/%{title}
I'll submit a patch later. For now, I'm working around this by setting a
constant inside my puppet define and matching against that in /etc/hiera.yaml,
but that's kind of a hack.
--
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.
